Skip to main content

Full text of "Proceedings of the hypertext standardization workshop January 16-18, 1990 National Institute of Standards and Technology"

See other formats


NIST  Special  Publication  500-178 


A111Q3  3fiTSbfl  . 

 v^uiripuc^r 

Systems 
Technology 

U.S.  DEPARTMENT  OF 
COMMERCE 
National  Institute  of 
Standards  and 
Technology 

Nisr 

NIST  * 
PUBLICATIONS 


Proceedings  of  the  Hypertext 
Standardization  Workshop 
January  16-18,  1990 
National  Institute  of  Standards 
and  Technology 


Judi  Moline 
Dan  Benigni 
Jean  Baronas 


NATIONAL  INSTrrUTE  OF  STANDARDS  & 
TECHNOLOGY 
Reseso'di  Mormatkm  Center 
Gakhersburg,  MD  20899 


DATE  DUE 

.  _  

r  ■ 



Demco,  Inc.  38-.293 

NIST  Special  Publication  500-178 


Proceedings  of  the  Hypertext 
Standardization  Workshop 
January  16-18,  1990 
National  Institute  of  Standards 
and  Technology 


Judi  Moline,  Dan  Benigni,  and  Jean  Baronas,  Editors 

Hypertext  Competence  Project 
National  Computer  Systems  Laboratory 
National  Institute  of  Standards  and  Technology 
Gaithersburg,  MD  20899 

March  1990 


U.S.  DEPARTMENT  OF  COMMERCE 
Robert  A.  Mosbacher,  Secretary 

NATIONAL  INSTITUTE  OF  STANDARDS 
AND  TECHNOLOGY 
John  W.  Lyons,  Director 


Reports  on  Computer  Systems  Technology 


The  National  Institute  of  Standards  and  Technology  (NiST)  (formerly  the  National  Bureau  of  Standards) 
has  a  unique  responsibility  for  computer  systems  technology  within  the  Federal  government.  NIST's 
National  Computer  Systems  Laboratory  (NCSL)  develops  standards  and  guidelines,  provides  technical 
assistance,  and  conducts  research  for  computers  and  related  telecommunications  systems  to  achieve 
more  effective  utilization  of  Federal  information  technology  resources.  NCSL's  responsibilities  include 
development  of  technical,  management,  physical,  and  administrative  standards  and  guidelines  for  the 
cost-effective  security  and  privacy  of  sensitive  unclassified  information  processed  in  Federal  computers. 
NCSL  assists  agencies  in  developing  security  plans  and  in  improving  computer  security  awareness  train- 
ing. This  Special  Publication  500  series  reports  NCSL  research  and  guidelines  to  Federal  agencies  as  well 
as  to  organizations  in  industry,  government,  and  academia. 


National  Institute  of  Standards  and  Technology  Special  Publication  500-178 
Natl.  Inst.  Stand.  Technol.  Spec.  Publ.  500-178,  259  pages  (Mar.  1990) 

CODEN:  NSPUE2 


U.S.  GOVERNMENT  PRINTING  OFFICE 
WASHINGTON:  1990 


For  sale  by  the  Superintendent  of  Documents,  U.S.  Government  Printing  Office,  Washington,  DC  20402 


PREFACE 


This  report  constitutes  the  proceedings  of  a  three  day  workshop  on  Hypertext 
Standardization  held  at  the  National  Institute  of  Standards  and  Technology  (NIST)  on 
January  16  -  18,  1990.  The  workshop  was  the  first  in  what  we  hope  becomes  a  series  of 
standardization  efforts.  The  workshop  was  sponsored  by  the  Hypertext  Competence 
Project  of  the  National  Computer  Systems  Laboratory  of  NIST. 

The  workshop  included  plenary  sessions  and  three  disscussion  groups.  Because  the 
participants  in  the  workshop  drew  on  their  personal  experiences,  they  sometimes  cited 
specific  vendors  and  commercial  products.  The  inclusion  or  omission  of  a  particular 
company  or  product  does  not  imply  either  endorsement  or  criticism  by  NIST. 

We  of  the  Hypertext  Competence  Project  gratefully  acknowledge  the  assistance  of  all 
those  who  made  the  workshop  a  success.  Further,  I  want  to  thank  Dave  Stotts  for 
designing  the  cover  graphic. 

Judi  Moline 
January  29,  1990 


PROGRAM  COMMITTEE 

Len  Gallagher,  Chairman 

Jean  Baronas 

Dan  Benigni 

Richard  Fumta 

Judi  Moline 

David  Stotts 


-  iii  - 


CONTENTS 


ABSTRACT   1 

INTRODUCTION   3 

REPORTS  OF  DISCUSSION  GROUPS    5 

1.  HYPERTEXT  MODELS  DISCUSSION  GROUP   7 

1.1  Reference  and  Data  Model  Group:  Work  Plan  Status   9 

1.2  Reference  and  Data  Model  Group:  Comparison  of  Three 

Models   15 

1.3  Reference  and  Data  Model  Group:  Responses  to    17 

2.  DATA  INTERCHANGE  DISCUSSION  GROUP    19 

2.1  Summar>' of  the  Hypertext  Interchange  Group   21 

2.2  Note  on  Representing  Anchors   23 

3.  USER  REQUIREMENTS  DISCUSSION  GROUP   27 

3.1  Report  from  the  User  Requirements  Working  Group    29 

PAPERS    37 

1.  Bomstein,  J.  &  Riley,  V.  -  Hypertext  Interchange  Format   39 

2.  Brown,  P.J.  —  Standards  for  Hypertext  Source  Files:  the  Experience  of  UNIX 
Guide   49 

3.  Cole,  F.  &  Brown,  H.    Standards:  What  Can  Hypertext  Learn  from  Paper 
Documents?   59 

4.  Crane,  Gregory  --  Standards  for  a  H3/permedia  Database:  Diachronic  vs. 
Synclironic  Concerns    71 

5.  Furuta,R.  &  Stotts,P.D. -The  Trellis  Hypertext  Reference  Model  ....  83 

6.  Halasz,  F.  &  Schwartz  M.  -  The  Dexter  Hypertext  Reference 

Model   95 

7.  Hardt-Komzacki,  S.  et  al.  -  Standardization  of  Hypermedia:  What's  the 

Point?   135 

8.  Lange,  Danny  B.  -  A  Formal  Model  of  Hypertext   145 

9.  Marshall,  Catherine  C.  -  A  Multi-Tiered  Approach  to  Hypertext  Integration: 
Negotiating  Standards  for  a  Heterogeneous  Application 

Environment   167 

10.  Newcomb,  Steven  R.  -  Explanatory  Cover  Material  for  Section  7.2  of 

X3V1.8M/SD-7   179 


-  V- 


1 1 .  Oren,  Tim  -  Toward  Open  Hypertext:  Requirements  for  Distributed 
Hypermedia  Standards  189 

12.  Parunak,  H.  Van  Dyke  -  Toward  a  Reference  Model  for 

Hypermedia   197 

13.  Riley,  Victor  A.  -  An  Interchange  Format  for  Hypertext  Systems:  the 

Intennedia  Model  213 

14.  Thompson,  Craig  W.  -  Strawman  Reference  Model  for  Hypermedia 

Systems  223 

APPENDICES  247 

1.  Kahn,  Paul -Hypermedia  Bibliography,  1989    249 

2.  Participants  265 


-  vi 


ABSTRACT 


This  report  constitutes  the  proceedings  of  a  three  day  workshop  on  Hypertext 
Standardization  held  at  the  National  Institute  of  Standards  and  Technology  (NIST)  on 
January  16  -  18,  1990.  Efforts  towards  standardization  of  hypertext  have  already  been 
initiated  in  various  interested  organizations.  In  recognition  of  these  existing  efforts,  NIST 
sponsored  the  Hypertext  Standardization  Workshop  organized  by  the  Hypertext 
Competence  Project  of  the  National  Computer  Systems  Laboratory. 

The  major  purpose  of  the  Hypertext  Standardization  Workshop  was  to  provide  a 
forum  for  presentation  and  discussion  of  existing  and  proposed  approaches  to  hypertext 
standardization.  The  stated  workshop  goals  were  to  consider  hypertext  system  definitions, 
to  identify  viable  approaches  for  pursuing  standards,  to  seek  commonality  among 
alternatives  whenever  possible,  and  to  make  progress  towards  a  coordinated  plan  for 
standards  development,  i.e.  a  hypertext  reference  model.  The  workshop  announcement 
solicitated  contributed  papers  on  any  aspect  of  hypertext  standardization,  including 
assertions  that  standardization  is  premature  or  inadvisable.  Approximately  30 
contributions  were  received  and  distributed  to  the  65  workshop  participants  on  the  first 
day. 

The  workshop  included  plenary  sessions  and  three  discussion  groups.  This 
proceedings  includes  the  papers  selected  for  presentation  in  plenary  sessions,  reports  of 
the  discussion  groups,  and  supplementary  materials.  Major  conclusions  of  the  workshop 
were  that  the  discussion  groups  should  continue  their  technical  efforts,  and  that  NIST 
should  sponsor  at  least  one  more  workshop  to  provide  a  forum  for  public  discussion  of 
progress. 

Key  words:  hypermedia;  hypertext;  standards. 


-1- 


INTRODUCTION 


Over  the  past  several  years  we  have  seen  a  significant  increase  in  the  availability  of 
document  and  information  management  systems  that  call  themselves  Hypertext  or 
Hypermedia  implementations.  These  systems  have  received  a  degree  of  acceptance  from 
the  user  community  and  are  being  integrated  into  an  increasing  number  of  application 
development  projects.  There  is  every  reason  to  believe  that  this  trend  will  continue  to 
grow  and  influence  the  marketplace  in  the  foreseeable  future. 

Although,  at  present,  Hypertext/Hypennedia  systems  have  no  agreed  formal 
definition,  there  is  agreement  on  some  of  the  underlying  concepts  that  characterize  them. 
Recently,  a  number  of  authors  have  stated  requirements  for  hypertext  standards  and  some 
have  offered  definitions  and  initial  specifications  for  consideration.  In  several  cases, 
specialized  standardization  efforts  have  already  been  initiated  through  interested 
organizations.  In  recognition  of  this  emerging  activity,  the  National  Institute  of  Standards 
and  Technology  (NIST)  sponsored  the  Hypertext  Standardization  Workshop.  One 
consideration  of  the  workshop  was  to  determine  if  the  evolution  of  Hypertext  and 
Hypermedia  technologies  has  reached  the  point  where  it  makes  sense  to  consider  formal 
standardization. 

The  major  purpose  of  the  Hypertext  Standardization  Workshop  was  to  provide  a 
forum  for  presentation  and  discussion  of  existing  and  proposed  approaches  to  hypertext 
standardization.  We  solicitated  contributed  papers  on  any  aspect  of  hypertext 
standardization,  including  assertions  that  standardization  is  premature  or  inadvisable.  We 
received  approximately  30  contributions  totaling  more  than  400  pages,  which  were 
distributed  to  all  workshop  participants  on  the  first  day.  The  stated  workshop  goals  were 
to  consider  hypertext  system  definitions,  to  identify  viable  approaches  for  pursuing 
standards,  to  seek  commonality  among  alternatives  whenever  possible,  and  to  make 
progress  towards  a  coordinated  plan  for  standards  development,  i.e.,  a  hypertext  reference 
model. 

Of  the  contributed  papers,  those  of  particularly  high  quality  and  general  interest  were 
accepted  for  publication  and  featured  during  a  plenary  session  on  the  opening  day  of  the 
workshop.  Each  author  was  given  approximately  25  minutes  to  present  a  particular  point 
of  view.  These  individual  papers  are  presented  alphabetically  in  this  proceedings.  The 
remainder  of  the  first  day  and  all  of  the  second  day  consisted  of  discussion  groups  set  up 
in  response  to  issues  raised  in  the  contributed  papers. 

Three  discussion  groups  met  in  parallel  on  the  topics  of  Hypertext  Models,  Hypertext 
Data  Interchange,  and  Hypertext  User  Requirements.  Each  group  chose  one  or  more 
"Presentors"  to  convey  group  opinions  to  the  whole  workshop.  Summaries  of  the 
deliberations  and  conclusions  of  these  discussion  groups,  authored  by  the  presentors,  are 
included  herein. 


The  morning  of  the  third  day  of  the  workshop  consisted  of  reports  from  each  of  the 
three  discussion  groups  and  a  general  discussion  of  where  to  go  from  here.  In  general,  the 
groups  were  quite  pleased  with  their  progress  and  expressed  a  desire  to  meet  on  a 
somewhat  regular  basis  to  continue  deliberations.  There  was  general  agreement  that  a 
recognized  hypertext/hypermedia  standards  group  could  function  as  the  focal  point  in 
defining  a  hypertext  data  model  and  a  reference  model  that  addresses  other  more 
specialized  activities  in  areas  such  as  documents,  graphics,  video,  and  sound. 

Craig  Thompson  raised  the  issue  of  establishing  a  more  formal  hypertext/hypermedia 
"study  group"  with  regular  scheduled  meetings  and  operating  procedures.  Possibilities  for 
organizing  such  a  group  under  the  auspices  of  ACM,  X3,  IEEE,  GCA,  MIST,  or  some 
other  ANSI  accredited  organization  were  discussed,  but  with  no  definitive  conclusion. 
Interested  individuals  were  encouraged  to  pursue  possibilities  within  these  organizations. 

Major  conclusions  of  the  workshop  were  that  the  individual  discussion  groups  should 
continue  their  respective  technical  efforts,  possibly  via  private  communications,  and  that 
NIST  should  sponsor  at  least  one  more  workshop  to  provide  a  fomm  for  public  discussion 
of  progress.  A  decision  could  then  be  made  as  to  the  desirability  of  establishing  a  more 
formal  standardization  group  with  status  in  some  ANSI  accredited  standards  organization. 

Leonard  Gallagher 
Workshop  Chairperson 


-4- 


REPORTS  OF  DISCUSSION  GROUPS 


This  section  of  the  proceedings  contains  the  reports  as  submitted  by  the  presenters  of  the 
discussion  groups.  The  material  was  presented  at  the  closing  plenary  of  the  workshop. 


-5- 


1.  HYPERTEXT  MODELS  DISCUSSION  GROUP 


Moderator: 

Judi  Moline 

Presentors' 

Van  Pariinak 

John  Le?eett 

Jim  Black 

Scribe: 

Robert  Miglin 

JiJliii  L/C^gjCLL 

W/i 111 T  r^fti  1  c 
VV  llllalii  IvUilUo 

James  Black 

Robert  Miglin 

John  C.  Chen 

Judi  Moline 

Qi  Fan  Chen 

Howard  Moncarz 

Paul  Clapis 

Taeha  Park 

Fred  Cole 

Van  Parunak 

Andrew  Dove 

John  Puttress 

Robert  Edmiston 

Louis  Roberts 

Lawrence  Fitzpatrick 

Linda  Rosenberg 

Richard  Furuta 

Andrea  Spinelli 

Frank  Halasz 

David  Stotts 

Shoshana  Hardt-Komacki     Craig  Thompson 

Kris  Houlahan 

Magda  Wright 

Danny  Lange 

Reports  of  this  group  follow: 

•  Reference  and  Data  Model  Group:  Work  Plan  Status 

•  Reference  and  Data  Model  Group:  Comparison  of  Three  Models 

•  Reference  and  Data  Model  Group:   Responses  to  "Issues  for  Discussion  Group 
Consideration" 


-7- 


Reference  and  Data  Model  Group  (RDMG): 
Work  Plan  Status 


Reported  by 
H.  Van  Dyke  Parunak 
Industrial  Technology  Institute 

January  26,  1990 


Abstract 

A  reference  model  is  a  structured  description  of  some  domain  that  can  be  used  to  compare  existing  imple- 
mentations in  that  domain,  design  new  implementations,  and  (most  important  for  our  purposes)  map  out 
possible  areas  for  standardization  and  show  their  relation  to  one  another.  The  main  output  of  the  RDMG 
during  the  NIST  workshop  was  a  work  plan  for  arriving  at  such  a  reference  model.  The  wwk  plan  that 
we  propose  has  the  following  structure,  where  the  flow  of  activity  is  down  the  page  (except  for  the  single 
feedback  loop),  and  where  activities  marked  by  '*'  received  significant  attention  during  the  workshop. 

+  +  +  + 

I  I  II 

V                                        V  V  I 

♦Define                  *Brainstorm  *Coinpare  Existing  I 

"Hypertext"           Concepts  Models  (DTL)  I 

\                 I                 /  I 

\               V               /  1 

♦Organize  Ontology  I 

1  I 

V  I 
Rank  Concepts  by  Centrality  I 

I  I 

V  I 
Inventory  Existing  Systems  I 

I  I 

V  I 
Construct  "Implementation"  Model  I 

I  I 
+  + 

V 

Select  Areas  for  Standards 

The  rest  of  this  document  defines  each  of  these  steps,  and  reports  what  we  have  done  in  each  of  them. 

This  document  summarizes  the  portion  of  the  final  RDMG  presentation  that  I  delivered  on  18  January 
1990.  It  represents  my  perception  of  the  deliberations  of  the  group,  but  has  not  been  reviewed  or  formally 
approved  by  the  other  members. 


1     Define  'Hypertext' 


This  definition  is  intended  to  be  a  brief,  succinct  statement  of  our  domain,  to  provide  some  degree  of  focus 
during  subsequent  stages.  It  may  well  change  considerably  as  a  result  of  later  analysis.  We  began  with 
a  definition  that  has  been  circulating  for  several  years,  and  modified  it  to  reflect  the  valuable  distinction 
between  'hypertext'  (as  a  structured  body  of  information)  and  'hypertext  system': 

A  Hypertext  is  a  network  of  information  nodes  connected  by  means  of  relational  links. 

A  Hypertext  System  is  a  configuration  of  hardware  and  software  that  presents  a  Hypertext  to  users  and 
allows  them  to  manage  and  access  the  information  that  it  contains. 

2  Brainstorm  Concepts 

In  an  effort  to  scope  our  discussions,  we  brainstormed  terms  and  concepts  describing  hypermedia,  and 
assembled  a  list  of  about  80.  These  are  listed  in  more  organized  fashion  below. 

3  Compare  Existing  Models 

In  order  to  build  on  existing  work,  representatives  of  three  detailed  models  presented  at  the  workshop  (the 
Dexter  model,  the  Trellis  r- model,  and  Danny  Lange's  model)  compared  and  contrasted  their  respective 
models.  A  separate  report  by  John  Leggett  summarizes  those  discussions. 

4  Organize  Ontology 

We  attempted  to  organize  the  set  of  terms  and  concepts  to  bring  like  things  together.  This  section  reviews 
the  resulting  taxonomy  of  concepts,  and  then  describes  some  further  analysis  that  might  be  conducted  to 
organize  the  list  even  further.  By  itself,  this  organized  list  is  a  limited  reference  model.  Subsequent  steps 
refine  it  and  seek  to  cast  it  in  a  form  that  has  been  useful  in  the  past  in  guiding  the  development  of  standards. 

4.1     A  Preliminary  Organization 

We  found  it  useful  to  sort  the  concepts  produced  by  brainstorming  into  three  main  categories:  Entities, 
Properties,  and  Functions  or  Operations.  Some  concepts  did  not  seem  to  fit  cleanly  into  any  of  these,  and 
were  relegated  to  a  catch-all  category,  Abstractions. 

Entities  These  are  the  objects  that  a  hypertext  system  must  manipulate;  together,  they  make  up  a  hy- 
pertext. 

•  Components,  each  with  a  UID  (unique  ID) 

—  Link  or  relationship;  may  be  warm,  hot,  abstract,  dynamic. 

~  Nodes;  can  have  fields,  contents,  anchors/buttons/interactors/Iink  markers 

—  Composites,  including  idioms,  paths,  tours,  webs,  networks 

•  Whole  documents,  also  with  UID's  (container,  stack,  frame  set,  guideline) 

•  Navigational  aids,  including  index,  map,  table  of  contents,  fisheye  view 

•  Display  entities:  window,  canvas.  Card  vs.  scroll  distinction  applies  here. 

•  Functional  stuff:  presentation  specification;  resolver. 


-10- 


Properties    These  can  be  either  of  entities  or  of  the  entire  system. 

•  Properties  of  Entities  (should  probably  be  merged  with  the  Entity  term  list) 

—  Attributes  (of  nodes  and  links;  includes  temporal  and  display  behavior) 

—  Component  format  and  structure  (e.g.,  locktext) 

—  Network  topology  (e.g.,  hierarchy,  hypercube,  DAG) 

—  Size  of  canvas  (scroll  vs.  card) 

•  Properties  of  the  System 

—  Concurrency,  including  both  multiuser  and  multithread 

—  Synchrony 

—  Existence  of  a  formal  model 

—  System  performance  (e.g.,  speed) 

—  Timing  (e.g.,  to  support  music,  animation,  and  video) 

—  Distributed  vs.  local 

—  Monolithic  vs.  open  (as  in  a  link  service  or  link  protocol) 

—  Referential  integrity  (are  dangling  links  permitted?) 

—  Context  sensitivity 

—  Interoperability 

—  Operating  modes  (browse,  author,  ...) 

Functions  Initial  attempts  to  classify  these  further  were  unsuccessful.  We  finally  did  a  hierarchical  clus- 
tering, joining  the  closest  two  items  into  one,  and  repeating  until  we  had  a  reasonable  number  of  classes. 
This  process  yielded  the  following  taxonomy,  to  which  we  have  added  names  that  seem  to  summarize  the 
contents  of  each  group: 

•  Knowledge  modification 

—  Modifying  system  knowledge  in  place:  edit  (including  cut/paste  and  structured  editing),  update, 
annotate 

—  Move  information  into  or  between  systems:  interchange;  conversion  and  parsing  of  raw  text 

•  Navigation 

—  Search  and  query;  need  for  managing  relevance  of  search;  filters 

—  Browsing  semantics  (progressive  disclosure;  histories;  views;  path  macros;  bookmarks) 

—  Support  tools:  scripting,  addressability,  triggering  (actions  to  take  on  arriving  and  departing  a 
node) 

•  'Yucky  Systems  Stuff' 

—  Tailoring 

—  Interfaces,  of  two  sorts: 

*  Foreign  nodes  (application  programs  that  can  be  activated  at  a  node);  API's 

*  Communications  protocols  (between  separate  programs  at  the  same  layer)  and  services  (be- 
tween layers  of  a  single  program) 

—  Versioning,  journaling 

—  Access  control 


-11- 


Abstractions  This  is  a  catch-all  category  for  a  number  of  terms  that  didn't  seem  to  fit  elsewhere.  Alter- 
native titles  for  this  group  of  terms  are  'metadata'  and  'implementation  tools.' 

•  Schema 

•  Type 

•  Class 

•  Object 

•  Data  models  (E-R,  semantic) 

•  Encapsulation 

•  Layer 

4.2    Further  Organization 

One  can  go  further  (though  we  didn't  have  time).  For  example: 

•  Developing  a  'Properties  x  Functions'  relation  to  show  what  functions  are  needed  to  support  what 
(systems)  properties. 

•  Developing  an  'Entities  x  Functions'  relation  to  show  what  entities  support  what  functions. 

5  Rank  Concepts  by  Centrality 

In  choosing  areas  for  standardization,  we  want  to  focus  on  those  topics  that  are  characteristic  of  most  or  all 
hypermedia  systems,  and  not  on  those  that  appear  only  in  a  few  systems  for  special  purposes.  The  intent 
here  is  to  rank  each  topic  as  {-|-,0,— }  to  indicate  how  typical  or  critical  it  is  for  a  model  of  mainstream 
hypermedia. 

6  Inventory  Existing  Systems 

One  important  use  of  a  reference  model  is  as  a  guide  to  comparing  systems,  and  a  test  of  the  model  that 
this  process  produces  will  be  how  useful  it  is  for  such  comparisons.  We  propose  the  development  of  a  matrix 
showing  how  various  existing  systems  reflect  the  categories  that  we  have  developed,  as  a  way  of  testing  the 
completeness  and  consistency  of  our  ontology.  Discussion  in  the  plenary  session  on  this  point  highlighted 
the  different  results  that  would  likely  be  obtained  depending  on  whether  one  focused  on  commercial  systems 
or  on  research  systems. 

7  Construct  'Implementation'  Model 

The  objective  here  is  to  derive  a  layered  model,  like  the  OSI  reference  model,  in  which  the  layers  represent 
successive  functionality  added  to  a  core  with  hardware  at  the  bottom. 

The  group  expressed  some  difference  of  opinion  on  whether  OSI  is  a  good  example  of  what  we  want. 

An  interesting  discussion  within  the  group  centered  on  whether  a  monotonic  layering  from  hardware  to 
application  was  possible.  One  suggestion  was  that  in  fact  there  might  be  several  implementation  stacks, 
doing  different  tasks,  for  instance: 


-12- 


S  T  A 

C  K  S 

TASK: 

Store 

1  Process 

1  Present 

User 

LAYERS : 

Node .Link 
OODB 

File  System 

1  Navigate 

1  Window, Button 

1  Virtual 
1  Terminal 

Concept 

DEVICE: 

Disk 

1  CPU 

1  CRT/Keyboard 

1  Eye/ 
Hand 

\   /  \   /       \  / 

MEDIUM:  Bus  LAN  EM  Radiation 


The  layers  listed  in  this  diagram  are  incomplete,  but  illustrate  the  difference  between  those  that  are 
central  to  hypermedia  and  must  be  described  in  our  model  (above  the  dashed  line),  and  those  that  should 
be  developed  in  other  disciplines  (below  the  line).  What  is  critical  for  our  purposes  is  the  clear  definition  of 
the  services  that  connect  one  layer  to  another. 


8     Select  Areas  for  Standards 

Once  developed,  a  reference  model  helps  map  out  areas  for  standards.  Focus  is  important  here,  and  the 
model  helps  provide  it  in  two  dimensions.  The  ranking  of  concepts  in  the  ontology  shows  how  central  each  is 
to  hypermedia,  and  helps  us  focus  on  standardizing  those  concepts  most  likely  to  be  of  widespread  use.  The 
implementation  model  helps  us  identify  which  concepts  are  best  standardized  in  other  research  communities 
(such  as  CHI,  DB,  OOPS,  windowing  systems)  and  which  require  the  focused  attention  of  researchers  in 
hypertext.  Graphically,  the  focussing  process  seeks  to  identify  the  region  'X'  in  the  diagram  below  for 
standardization. 


CHI  I  I 

+  _V  

Which  HT     I       X  <— 

Community?  +_--_-------------- 

DB.  i  1 
OOPS  I  I 

+  •  

All  HT  few 
Systems  Systems 
How  central  is  it  to  hypertext? 


-13- 


Reference  and  Data  Model  Group: 
Comparison  of  Three  Models 

John  J.  Leggett 
Department  of  Computer  Science 
Texas  A&M  University 

The  Reference  and  Data  Model  working  group  spent  45  minutes  comparing  and  contrasting  the  R-model-^, 
Dexter"'  and  Lange^  reference  models.  David  Stotts,  Danny  Lange  and  John  Leggett  spent  another  90 
minutes  over  dinner  discussing  the  three  models.  A  summary  was  provided  by  John  Leggett  during  the  final 
plenary  session.  As  these  three  models  are  currently  under  development,  the  comparisons  are  rather  broad 
in  nature.  It  is  interesting  to  note  that  the  three  models  were  developed  independently  and  with  varying 
levels  of  collaboration.  The  results  of  these  discussions  are  presented  below  in  mostly  tabular  form. 


Differences 

Type  Links  Anchors  Formalized? 

R-model     Meta-model  for  No  links,  but  No  distinct  No 

systems  specification  relations  defined  anchors 

Lange        Model  of  hypertext  Allows  dangling  Anchors  and    Yes,  in  VDM 

links  regions 

Dexter       Model  of  hypertext  Does  not  allow  Anchors  Yes,  in  Z 

systems  dangling  links 


Similarities 

Support  for  types  in  all  three  models  is  through  arbitrary  attribute/ value  pairs. 
All  three  models  have  separated  content,  structure  and  presentation: 

Content  Structure  Presentation 


R-model    Abstract  content       Structure  and  Concrete  and 

abstract  containers  visible  levels 

Lange        Schema  Networks  and  Unspecified 

structures 

Dexter       Within-component    Storage  layer  Run-tim.e  la3'er  with 

layer  presentation  specifications 


^Ridiard  Furuta  and  P.  David  Stotts,  "The  Trellis  Hypertext  Reference  Model,"  these  proceedings. 
^ Frank  Halasz  and  Mayer  Sdiwartz,  "The  Dexter  Hypertext  Reference  Model,"  these  proceedings. 
^Danny  B.  Lange,  "A  Formai  Model  of  Hypertext,"  these  proceedings. 


-15- 


H>'pertext  Reference  Model  Group 
Responses  to  "Issues  for  Discussion  Group  Consideration" 

James  Black 

1.  What  is  the  current  state -of-aff airs  in  this  topic  area?  What  is  likely  to  happen  in  the 
near  future? 

The  Reference  Model  Working  Group  did  a  reasonably  thorough  examination  of  three 
independently  derived  hypertext  models  and  identified  no  essential  inconsistencies  which 
would  preclude  eventual  consensus.  Each  of  the  three  models  was  the  product  of  a 
different  analytical  approach  and  there  remain  significant  areas  of  confusion  and  lack  of 
current  consensus  which  seem  to  largely  due  to  syntactical  differences.  Further  open 
dialogue  among  the  participants  would  improve  this  situation. 

2.  Are  emerging  technologies  driving  this  topic  in  a  certain  direction?  Is  there  sufficient 
stability  to  warrant  further  pursuit  of  standardization  at  this  time? 

The  sessions  revealed  no  clear  evidence  that  "emerging  technology"  was  driving  any 
aspect  of  the  hypertext  concept  in  a  particular  direction.  The  only  indication  of  any 
"driving  forces"  which  may  be  prematurely  affecting  aspects  of  the  evolution  of  hypertext 
technology  are  related  to  other  standardization  efforts,  specifically,  ODA  and  5G(a  .  There 
does  seem  to  be  sufficient  stability  in  the  shared  understanding  of  basic  hypertext 
concepts  to  warrant  further  pursuit  of  standardization. 

3.  What  are  the  most  important  concepts?  Ale  there  agreed  definitions?  Is  there  a  glossary 
available,  or  set  of  candidate  key  words? 

The  essential  concepts  of  hypertext  would  include  a  data  model  with  the  following 
features: 

•  data  type  and  media  independence 

•  "fonnat"  and  "content"  independence 

•  freely  defined,  relational  links  between  freely  defined  data  elements 

•  no  inherently  hierarchical  structure 

•  distinct  separation  of  format  and  content 

They  would  also  include  such  functional  features  as  navigational,  authoring,  presentation, 
and  systems  management  tools. 

4.  What  is  the  interdependency  of  this  topic  area  with  other  topic  areas  identified  at  this 
workshop? 


-17- 


There  is  a  need  to  develop  a  glossary  and  taxonomy  of  hypertext  terminology  which 
includes  formal,  (mathematical)  definitions  where  available.  There  is  available  a  core  set 
of  candidate  key  words. 

5.  What  are  the  major  problems  and  controversies?  Is  compromise  possible?  or  would 
alternative  approaches  better  serve  the  vendor/user  communities? 

There  is  significant  interdependency  between  the  hypertext  reference  model  and 
system  interchange  issues. 

6.  What  is  the  ultimate  goal  for  this  topic  area?  a  user  guideline?  a  domestic  standard?  an 
intemational  standard?  something  else?  What  is  an  appropriate  sequence  of  steps  leading 
to  this  goal? 

The  ultimate  goal  of  this  working  group  is  to  establish  a  hypertext  system  reference 
model  and  use  it  to  establish  a  hypenext  glossary  and  taxonomy  and  to  identify  candidate 
areas  for  standardization  activity. 

7.  What  concepts  in  this  area  are  appropriate  for  standardization?  What  concepts  are  not 
appropriate  for  standards?  What  can  inhibit  the  development  of  standards?  Is  something 
ready  for  standardization  at  this  time? 

There  are  no  areas  ready  for  standardization  at  this  lime. 

8.  What  role  can  NIST  play  in  achieving  the  goals  of  this  topic?  Aiq  further  workshops 
desirable?  What  is  the  most  appropriate  follow -on  activity  after  this  workshop? 

NIST  can  establish  a  formal,  on-going  hypertext  study  group  that  publishes  consensus 
findings  and  recommendations  which  NIST  links  to  relevant  standards  organizations. 


-18- 


2.  DATA  INTERCHANGE  DISCUSSION  GROUP 


Moderator:      Len  Gallagher 
Presentor:       Tim  Oren 
Scribe:  Jan  Walker 


Rob  Akscyn 
Gregory  Crfine 
Valerie  Florance 
Edward  A.  Fox 
David  Fristrom 
Len  Gallagher 
Steve  Newcomb 
Charles  Nicholas 
Tim  Oren 
Kenneth  Pugh 
Victor  Riley 
Jan  Walker 


Reports  of  this  group  follow: 

•  Summary  of  the  Hypertext  Interchange  Group 

•  Note  on  Representing  Anchors 


-19- 


Summary'  of  the  Hypertext  Interchange  Group 


The  Interchange  Group  first  discussed  how  the  problem  could  be  partitioned.  We  agreed 
that  ideally  the  representation  of  the  data  and  its  presentation  to  the  user  should  be 
separated.  However,  for  efficiency  reasons  most  existing  hypertext  systems  which  support 
graphics  in  fact  store  bit  maps  and  specific  screen  coordinates.  This  is  an  obstacle  to 
interchange  between  platforms  with  differing  display  architectures. 

We  also  made  the  distinction  between  a  "delivery  interchange"  standard  and  an 
"archival  interchange"  standard.  A  delivery  interchange  standard  would  be  directly 
usable  by  a  conforming  hypertext  system  without  translation.  We  regarded  this  as  very 
difficult  to  achieve  in  the  short  term  due  to  differences  in  hypertext  systems'  methods  of 
storing  and  indexing  their  data,  which  are  usually  highly  optimized  for  the  particular 
platform  and  application.  The  dependence  on  display  formats  already  noted  is  also  an 
obstacle  to  a  delivery  interchange  standard. 

An  "archival  interchange"  standard  is  one  in  which  the  information  owner  may  store 
hypertext  in  a  system  independent  fashion.  For  actual  delivery  either  the  information 
owner  or  end  user  would  need  to  translate  the  archival  interchange  format  into  a  format 
specific  to  a  particular  hypertext  software/hardware  configuration.  Any  changes  authored 
by  the  end  user  would  have  to  be  rolled  back  to  the  archival  store  before  reaching  other 
platforms,  rather  than  attempting  direct  interchange.  We  agreed  that  this  goal  was  more 
achievable  in  the  shoit  run,  and  turned  our  discussion  in  this  direction,  but  without 
disputing  the  eventual  value  of  a  delivery  interchange  format,  or  the  need  for  further 
experiments  with  delivery  to  define  requirements  for  the  archival  representation. 

We  proceeded  to  compare  relevant  interchange  proposals  from  the  working  papers  or 
which  were  otherwise  drawn  to  the  attention  of  the  group.  These  included  a  discussion 
paper  submitted  by  Ken  Pugh,  Victor  Riley's  Intermedia  exchange  paper,  portions  of  the 
HyTime  proposal,  and  the  so-called  "HIP"  Hypertext  Interchange  Protocol  developed  at 
Apple,  Xerox  PARC  and  Brown  IRIS.  A  copy  of  the  HIP  paper  was  supplied  by  Victor 
Riley  of  Brown  IRJS.  The  group  voted  to  request  that  the  HIP  paper  (Bomstein  and  ROey. 
"Hypenext  Interchange  Format")  and  relevant  sections  of  HyTime  (Newcomb, 
"E.xplanatory  Cover..."  and  Section  7.2)  be  included  in  the  final  Proceedings  of  the  NIST 
Workshop. 

Comparing  these  formats  showed  that  all  were  adopting  a  partitioning  of  the  problem 
into  data  objects,  anchors,  and  links.  Anchors  form  the  data  object  type  specific  endpoints 
for  links.  While  there  were  abundant  differences  in  terminology,  a  first  reading  showed 
basic  conformance  to  this  layering,  and  we  agreed  that  this  should  be  drawn  to  the 
attention  of  the  modeling  group. 

It  was  also  noted  that  most  of  the  interchange  proposals  used  SGML  or  SGML-like 
markups.  After  some  discussion,  it  was  agreed  that  SGML  was  a  reasonable  basis  for 


-21- 


further  interchange  experiments.  This  position  is  adopted  without  prejudice  to  an 
eventual  standard,  due  to  a  number  of  panicipants'  concems  about  technical  issues  (e.g., 
efficiency,  limits  of  a  parser  driven  implementation),  and  prejudgment  of  the  decision 
process.  We  agreed  that  documents  resulting  from  these  discussions  should  be  conveyed 
to  the  HyTime  (ANSI  X3V1.M8)  committee  for  inclusion  in  their  working  document  set. 

A  general  discussion  of  related  standards  ensued.  There  was  consensus  that  wherever 
possible  hypertext  interchange  standards  should  incorporate  existing  media  type  standards 
without  requiring  changes  in  those  standards. 

An  ad  hoc  group  composed  of  Ed  Fox,  Steve  Newcomb,  Tim  Oren,  and  Victor  Riley 
met  during  the  evening  to  continue  the  comparison  of  the  various  interchange  proposals. 
They  reported  to  the  whole  group  that  they  had  succeeded  in  a  first  pass  reconciliation  of 
the  anchor  levels  of  HIP,  Intermedia  and  HyTime.  Their  notes  are  appended  in  the 
interchange  section  of  the  proceedings  (under  the  title  "Note  on  Representing  Anchors") 
rather  than  incorporated  here,  as  they  were  not  a  result  of  the  entire  group. 

The  whole  group  strongly  suggests  that  further  experiments  with  interchange  between 
existing  systems  be  undertaken.  We  noted  the  need  for  a  publicly  available,  editorially 
controlled  document  set  for  this  purpose.  This  should  be  in  the  few  hundred  to  few 
thousand  node  size,  marked  up  in  SGML  with  linking  information  provided.  Further 
volunteers  and  funding  for  these  experiments  are  an  issue.  Availability  of  a  free  or 
inexpensive  SGML  parser  is  required  if  universities  are  to  participate  in  the  experiments. 

We  identified  a  number  of  significant  issues  which  were  not  addressed  due  to  time 
constraints: 

•  Making  a  complete  list  of  relevant  data  type  standards 

•  Requirement  for  unique  nammg  and  identification  services,  which  is  a  problem  with 
wider  scope  than  hypertext  alone. 

•  Link  typing,  type  definition  and  hierarchies,  N-way  link  structures 

•  Composites  -  a  taxonomy  of  existing  uses  and  representations 

•  Versioning 

•  Representation  of  time-based  media,  e.g.,  music,  video,  and  links  conveying  timing 
information 

These  should  be  addressed  in  further  sessions,  as  they  all  influence  requirements  for  an 
interchange  standard  and  some  (particularly  link  tj^mg  and  composites)  are  the  subject  of 
active  research  and  controversy. 

Submitted  by  Tim.  Oren 
January  24,  1990 


-22- 


Note  on  Representing  Anchors 
Reported  by  Tim  Oren 


An  ad  hoc  subgroup  of  the  Interchange  working  group  met  to  compare  various  proposals 
for  archival  interchange.  It  was  composed  of  Ed  Fox,  Steve  Newcomb,  Tim  Oren,  and 
Victor  Riley.  These  notes  are  the  result  of  that  meeting.  They  are  a  first  pass  which  has 
not  been  considered  by  any  other  group.  See  the  summary  of  the  Interchange  group  for 
context  and  definition  of  terms. 

We  chose  to  proceed  by  focusing  on  the  anchor  or  "anchor-like"  portion  of  each 
proposal.  We  began  by  considering  how  the  features  of  the  Intermedia  Interchange  could 
be  added  to  the  HIP  proposal,  and  expressed  the  result  in  HIP-like  terms.  We  then 
attempted  to  reconcile  this  result  with  the  formalism  and  language  of  the  pertinent 
sections  of  HyTime.  Note  that  this  applies  only  to  anchors,  and  there  may  be  additional 
difficulties  in  reconciling  layering  strategies  when  we  look  at  the  link  layers  of  the  various 
proposals. 

1 .  Reconciliation  of  Intermedia  exchange  and  HIP 

This  is  a  semi-formal  presentation  of  patches  to  the  <ANCHOR>  section  of  the  HIP 
specification.  The  other  sections  of  HIP  have  not  yet  been  brought  into  conformance: 

<NAME>  -  optional,  ASCII  string,  user  displayed  or  for  use  of  system.  Usage  ideas:  this 
could  be  the  name  of  a  hypercard  button,  or  used  as  a  item  for  searching,  or  as  comments 
to  be  displayed  as  preview. 

<ID>  -  required,  a  unique  ID  in  a  format  TBD.  Uniquely  identifies  this  anchor  within  the 
scope  of  the  interchange  set. 

<CREATION>  -  optional. 

<WHEN>  -  Date/time  of  creation  in  a  standard  form  TBD.  Indicates  the  moment 
of  original  creation  of  the  anchor  (even  if  it  was  later  moved). 

<BY>  -  the  unique  ID  (TBD)  of  the  user/authority  who  created  the  anchor. 

<MODIFIED>*  -  optional,  optionally  multiple. 

<WHEN>  -  Date/time  of  the  pailicuiar  modify.  It  is  a  application  policy  maner 
whether  all,  just  the  latest,  or  no  mods  are  recorded. 


-23- 


<BY>  -  the  unique  id  of  the  modifying  user/authority. 

<VERSION>  -  a  unique  id  of  the  referenced  version.  How  to  use  this  is  a  policy 
matter  of  the  system.  If  it's  the  same  as  the  <ID>  of  this  anchor,  this  is  the  current 
version. 

<LOCATION>  -  required. 

<ANCHOR-OBJECT-ID>  -  required.  The  unique  ID  of  the  data  object  (file  - 
chunk  -  whatever)  to  which  this  anchor  refers. 

< ANCHOR- VALUE>+  -  object  type  specific,  required,  optionally  multiple.  Note 
that  this  could  refer  to  multiple  selections,  elements,  etc.  within  the  data  object. 

<PRESENT-SPEC>  -  object  type  specific,  optional,  regulates  how  the  anchor  is  to 
be  presented,  e.g.,  run  the  sound  editor  or  play  the  sound,  positioning  information 
for  the  3-D  editor  view  of  an  IGES  object. 

2.  Reconciliation  with  HyTime  terminology  (sections  under  7.2.5) 

HyTime  as  written  contains  within  its  "location"  layer  information  which  is  both  generic 
to  the  concept  of  anchor,  and  specific  to  certain  data  types.  We  try  to  separate  this  here. 
Again,  this  has  not  been  reconciled  with  the  link  layer  of  HyTime  or  HIP  and  problems 
might  emerge  there. 

The  general  concept  of  "endoc"  corresponds  to  the  HIP  <ANCHOR>  idea.  The  ID  within 
entloc  corresponds  directly  to  the  <ID>  in  HIP.  The  "dataent"  corresponds  to  the 
<ANCHOR-OBJECT-ID>  of  HIP. 

Notation  Data  Location  (ndloc)  is  HyTime 's  generic  anchor,  corresponding  directly  to  the 
HIP  construct  above.  Its  type  specific  part  is  represented  in  the  "formula,"  which 
corresponds  to  the  <ANCHOR-VALUE>  of  HIP.  "Snap"  should  probably  be  considered 
part  of  a  type-specific  constmct  rather  than  part  of  a  generic  anchor.  HIP  would  probably 
represent  it  as  part  of  the  <PRESENT-SPEC>.  A  reasonable  default  data  type  is 
undifferentiated  byte  stream. 

The  other  location  constructs  are  viewed  as  data  type  specific  anchors. 

Character  data  set  location  (cdloc)  is  an  anchor  into  sequences  of  ISO  defined  characters 
(NB:  this  is  not  the  same  thing  as  a  font  or  byte  sequence). 

Document  locations  (elemloc)  (7.2.5.2-3)  are  the  SGML  object  type  specific  anchor 
definitions.  Element  location  is  SGML  type  specific  and  identifies  a  single  "node"  within 


-24- 


the  hierarchical  structure  created  by  an  SGML  markup.  This  may  be  specified  using  an 
ID,  if  one  exists  for  the  node,  or  using  a  path  designator  from  the  root.  Point  location 
allows  anchoring  to  a  spot  within  an  element. 

All  of  these  constructs  might  be  further  generalized  by  allowing  multiple  "selections"  to 
be  incorporated  within  one  "location." 


-25- 


3.  USER  REQUIREMENTS  DISCUSSION  GROUP 


Moderator:     Jean  Baronas 
Presentor:       Robert  Glushko 
Scribe:  Seymour  Hanfling 


Carol  Adams 
Peter  Aiken 
Jean  Baronas 
Denise  Bedgord 
Tim  Bemers-Lee 
Kevin  Gamble 
Robert  Glushko 
Louis  Gomez 
Seymour  Hanfling 
Casey  Malcolm 
Catherine  Marshall 
Fontaine  Moore 
Dan  Olson 
Duane  Stone 
Clifford  Un 
David  Wojick 
Don  Young 


Reports  of  this  group  follow: 
•  Report  from  the  User  Requirements  Working  Group 


REPORT  FROM  THE  USER  REQUIREMENTS  WORKING  GROUP 


Robert  J.  Glushko 

Search  Technology 
Norcross,  GA 

This  report  summarizes  meetings  held  on  January  16-17,  1990  during  a  workshop  on 
Hypermedia  Standardization  held  at  the  National  Institute  of  Standards  and  Technology  in 
Gaithersburg,  MD.  In  addition  to  the  author,  the  members  of  the  Working  Group  for  User 
Requirements  were  Carol  Adams,  Peter  Aiken,  Jean  Baronas,  Denise  Bedford,  Tim  Bemers-Lee, 
Valerie  Florence,  Kevin  Gamble,  Louis  Gomez,  Seymour  Hanfling,  Kathryn  Malcolm,  Cathy 
Marshall,  Fontaine  Moore,  Dan  Olson,  Duane  Stone,  Clifford  Uhr,  David  Wojick  and  Don 
Young.  The  group  followed  an  agenda  set  by  NIST  to  identify  the  current  state  of  affairs, 
important  driving  and  constraining  factors,  potential  areas  for  standardization,  and  research 
needs. 

Complete  consensus  on  these  complex  topics  was  impossible  in  two  days  for  a  group  this 
size,  so  this  report  emphasizes  the  majority  themes  for  the  issues  that  received  the  most  attention. 
I  apologize  for  my  own  biases,  which  undoubtedly  show  through. 

THE  CURRENT  STATE  OF  AFFAIRS  FOR  HYPERTEXT 

In  recent  years  hypertext  concepts  for  making  information  more  accessible  and  usable 
have  been  applied  to  a  bewildering  variety  of  applications: 

Reference  books,  encyclopedias,  dictionaries 
Library  collections  and  archival  literature 
Online  software  reference  manuals 
Policies,  procedures,  regulations 
Maintenance  and  diagnostic  information 
Online  help  systems  and  embedded  training 
Education,  tutorials 
Engineering  and  CAD 
Professional  project  management 
Collaborative  problem-solving  and  authoring 
Interactive  fiction,  entertainment 
Museum  directories  and  information  kiosks. 


-29- 


Four  basic  factors  appear  to  account  for  the  rapid  spread  of  hypertext  design  concepts. 
These  are  enabling  technology,  documentation  standards  initiatives  with  hypertext  implications, 
market  pressure,  and  academic  interest. 

Enabling  technology.  Hypertext  applications  require  a  significant  amount  of  local 
processing  power  and  storage  capacity  that  until  the  mid  1980s  was  not  readily  available. 
Hypertext  (and  espec'ally  hypermedia)  applications  are  also  benefiting  from  increased  data 
transfer  capabilities  enabled  by  advances  in  data  compression,  fiber  optics,  and  progress  toward 
an  end-to-end  digital  telecommunications  network.  Nevertheless,  having  the  delivery  and 
storage  technology  base  for  hypertext  systems  would  have  been  meaningless  without  the 
concurrent  maturation  of  user  interface  design  concepts  and  tools.  Object-oriented  programming 
and  prototyping  toolkits  that  embody  direct  manipulation  user  interface  concepts  make  it 
possible  to  design  and  implement  the  rich  functionality  of  hypertext  systems  in  a  cost-effective 
way. 

Documentation  standards  initiatives  with  hypertext  implications.  Some  major 
standards  efforts  in  related  areas  have  made  hypertext  both  more  necessary  and  more  likely.  The 
first  of  these  is  SGML,  the  Standard  Generalized  Markup  Language  [7].  In  1986  SGML  became 
an  international  standard  (ISO  8879)  for  defining  the  logical  structure  of  printed  documents 
independently  of  theii^  appearance.  While  there  is  no  agreement  that  SGML  is  the  optimal 
starting  point  for  a  hypertext  standard,  there  is  little  dispute  that  SGML's  system-independent 
markup  makes  it  significantly  easier  to  exchange  and  process  electronic  documents  and  hence,  to 
combine  them  into  hypertext  documents. 

A  second  major  standards  initiative  that  is  emerging  as  a  driving  force  for  hypertext  is 
CALS,  the  U.S.  Department  of  Defense  program  for  Computer-Aided  Acquisition  and  Logistic 
Support  [3].  CALS  has  as  its  goal  the  creation  of  a  "paperless  environment"  with  the  integration 
of  the  various  "islands  of  automation"  that  participate  in  the  system  design,  development, 
deployment,  and  maintenance  processes.  In  February  1988  the  CALS  program  adopted  SGML 
as  a  military  standard  (MIL-M-28001)  for  the  digital  form  of  traditional  printed  documents,  but 
new  standards  for  creating,  exchanging,  and  delivering  information  are  evolving  that  completely 
do  away  with  any  notion  of  "printed  page."  Since  so  many  companies  do  business  either  directly 
or  indirectly  with  the  Department  of  Defense,  the  scope  of  CALS  will  be  enormous.  The 
obvious  benefits  of  digital  information  exchange  throughout  the  entire  government  are  causing 
CALS  concepts  and  requirements  to  spill  over  into  other  parts  of  government. 

Market  pressure.  Programs  that  called  attention  to  their  hypertext  features  had  started  to 
emerge  in  the  mid- 1980s,  but  since  the  release  and  aggressive  marketing  of  HyperCard  by  Apple 
Computer  in  1987,  dozens  of  other  software  products  that  claim  to  provide  hypertext  and 
hypermedia  capabilities  have  entered  the  marketplace  since. 

Academic  interest.  Finally,  substantial  academic  interest  in  hypertext  issues  has 
emerged  in  the  last  few  years.  In  late  1987,  approximately  the  same  time  as  the  introduction  of 
HyperCard,  a  conference  was  held  at  the  University  of  North  Carolina  that  was  the  first 
academic  rally  of  researchers  and  system  designers  under  the  hypertext  flag  [1],  Since  then, 
similar  conferences  have  been  held  in  Europe  [9]  and  a  second  major  conference  on  hypertext 


-30- 


was  held  in  Pittsburgh  in  November  1989 
established  with  "hyper"  in  its  name  [6]. 


[2].  At  least  one  new  professional  journal  has  been 


THE  FUTURE 

The  1990s  will  see  ubiquitous  software  and  hardware  support  for  hypermedia 
applications  in  "off  the  shelf  computing  environments.  Computer  hardware,  software,  and 
telecommunications  companies  will  develop  business  strategies  and  product  lines  for  multimedia 
systems,  appUcations,  and  services. 

It  is  already  readily  apparent  that  no  single  hypertext  design  or  hypertext  software  is 
appropriate  for  all  applications  or  users.  However,  guidelines  or  standards  for  choosing  design 
approaches  or  software  tools  are  hard  to  apply  without  a  framework  for  understanding  the  range 
of  possible  applications  into  which  hypertext  solutions  might  fit. 


NEW  VIEWS  OF  THE  HYPERTEXT  "  DESIGN  SPACE" 

Nevertheless,  the  classification  scheme  for  hypertext  applications  that  this  paper  began 
with  is  too  arbitrary  to  serve  this  important  purpose.  That  scheme  loosely  categorizes  hypertext 
applications  according  to  the  kind  of  information  they  contain,  but  has  no  rationale  for  defining 
the  categories.  Why  aren't  encyclopedias  and  dictionaries  in  their  own  categories?  Shouldn't 
training  and  education  be  together?  Clearly,  a  more  abstract  and  robust  scheme  is  needed  for 
comparing,  understanding,  and  generating  hypertext  applications.  The  working  group  discussed 
several  alternative  views  of  the  "hypertext  design  space." 

Dimensional  view 

An  alternative  that  I  have  been  developing  is  based  on  four  non-orthogonal  dimensions: 

User  dimension:  single  users  vs.  groups  vs.  multiple  unrelated  users.  Hypertext 
systems  can  be  designed  for  single  users,  groups  of  users  working  collaboratively,  or  large 
communities  of  unrelated  users. 

Information  dimension:  creation  vs.  conversion.  Hypertexts  can  primarily  contain  new 
information  created  for  the  application  or  information  obtained  by  converting  information  that 
already  exists  in  conventional  printed  form. 

Task  dimension:  task-specific  vs.  general.  Hypertext  systems  can  be  designed  to 
support  specific  tasks  or  as  general-purpose  environments  for  building  other  hypertexts. 

Interface  dimension:  static  vs.  dynamic.  Hypertexts  can  be  primarily  static  archives  for 
read-only  browsing,  can  be  relatively  transient  databases  of  periodically-published  information 


-31- 


like  news  articles  or  product  catalogs,  or  dynamic  to  support  continuous  collaborative  authoring 
and  commentary. 

To  edit,  or  not  to  edit? 

An  alternative  framework  for  understanding  the  hypertext  design  space  was  proposed  by 
Carol  Adams.  Her  view  is  that  all  hypertext  applications  can  be  partitioned  according  to  whether 
or  not  they  allow  users  to  edit  the  content  of  the  basic  hypertext  units  and  the  links  between 
them.  These  two  orthogonal  dimensions  yield  four  cells  into  which  existing  and  potential 
hypertext  applications  might  be  categorized. 

The  two  clearest  categories  in  this  framework  are  applications  in  which  both  units  and 
links  can  be  edited,  and  "read-only"  or  pure  "browsing"  applications  in  which  neither  can. 
Applications  of  hypertext  to  software  design  or  concurrent  engineering  domains  might  embody  a 
fixed  structure  between  unit  templates  and  thus  primarily  support  unit-only  editing.  Finally, 
applications  that  involve  primarily  link-only  editing  with  permanent  units  might  include  archives 
or  literary  criticism. 


SPECIFICATION  OF  HYPERTEXT  FUNCTIONS 

Standards  for  the  appearance  of  hypertext  user  interfaces  may  not  even  be  possible  and 
are  certainly  premature.  The  range  of  applications  that  call  themselves  hypertext  and  the  wide 
assortment  of  user  interfaces  they  contain  clearly  argue  that  at  best,  subsets  of  standards  or 
standards  "families"  would  be  appropriate.  However,  the  working  group  concluded  that  users 
and  application  developers  would  benefit  immediately  from  shared  definitions  and  specifications 
for  hypertext  functions.  "Functions"  are  defined  here  as  operations  carried  out  by  a  hypertext 
user  interface  on  the  entities  managed  by  the  hypertext  storage  layer  [5]. 

The  goals  of  specifications  for  hypertext  functions  are  straightforward.  They  must: 

a)  fit  clearly  into  the  hypertext  reference  model, 

b)  be  independent  of  presentation  specifications,  and 

c)  unambiguously  define  the  operational  semantics. 

If  these  goals  can  be  satisfied,  perhaps  standards  for  hypertext  functions  can  emerge  that 
can  be  organized  into  consistent  subsets  for  different  parts  of  the  hypertext  design  space.  Then, 
the  interoperability  of  hypertext  systems  in  the  same  region  of  the  design  space  can  be  defined  in 
terms  of  these  functions.  The  working  group  began  this  ambitious  effort  by  creating  a  list  of 
functions  and  crudely  separating  them  into  "authoring"  and  "reader"  subsets.  No  claim  is  made 
that  these  lists  are  complete. 

Authoring  Functions 

1)  Create  (unit,  Unk,  composite) 


-32- 


2)  Edit  (unit,  link,  composite) 

3)  Delete  (unit,  link,  composite) 

4)  Publish  (unit,  link,  composite,  hypertext).  "Publish"  means  to  give  a  hypertext 
component  a  degree  of  permanence  in  some  current  version  or  configuration  of 
the  storage  layer. 

Reader  Functions 

1)  Indicate  current  unit 

2)  Move  to  another  unit 

a)  defined  spatially  (e.g.,  arbitrary  new  location  in  display) 

b)  defined  syntactically  (e.g.,  in  order  -  "next,"  "back") 

c)  defined  lexically  (e.g.,  unit  name  contains  string  "x") 

d)  defined  semantically  (e.g.,  unit  of  type  "x") 

e)  defined  temporally  (e.g.,  previous  current  unit) 

3)  Indicate  presence  of  "expandable"  structure 

4)  Indicate  whether  currently  expanded 

5)  Expand  current  unit 

6)  Close  current  unit 

Annotation  Functions 

7)  Create  annotation 

8)  Edit  annotation 

9)  Delete  annotation 

Bookmark  Functions 

10)  Create  bookmark 

a)  implicitly  when  in  unit 

b)  explicitly  by  user  action 

11)  Delete  bookmark 

12)  Move  to  "book-marked  unit" 

Functions  on  Virtual  Structures 

13)  Search  (scope,  specification) 

14)  Define  session  (history,  bookmarks,  annotations) 


-33- 


15)  Save  session 

16)  Restore  session 

Miscellaneous  Functions 

17)  Print  (Unit,  link,  linearization) 

Specifying  Functional  Semantics 

These  lists  of  functions  will  be  far  more  useful  when  accompanied  by  precise  definitions 
of  what  they  mean  and  the  rules  by  which  they  can  be  combined.  There  are  many  notations  for 
specifying  the  semantics  of  functions  (e.g.,  [4]),  but  I  will  use  an  informal  approach  here  that  is 
commensurate  with  the  rudimentary  level  of  the  working  group's  progress  in  developing  the 
specifications. 

For  example,  BACK  (NEXT  (X))  =  X  defines  the  meaning  of  "NEXT"  and  "BACK" 
functions  in  a  hypertext  system  as  follows:  if  a  reader  navigates  from  a  unit  X  using  a  "NEXT" 
function,  the  "BACK"  function  returns  to  the  starting  unit  X. 

Similarly,  DELETE  (CREATE  (X))  =  CREATE  (DELETE  (X)). 

But,  DELETE  (PUBLISH  (CREATE  (X)))  is  not  equal  to  DELETE  (CREATE  (X)), 
because  the  intervening  "PUBLISH"  function  defines  a  different  version  or  configuration  of  the 
hypertext. 


RESEARCH  AGENDA 

The  working  group  concluded  that  research  is  needed  in  many  cases  to  help  define  the 
appropriate  semantics  for  hypertext  functions,  and  it  would  be  appropriate  for  NIST  to  conduct, 
sjwnsor,  or  encourage  this  research.  Research  is  also  needed  to  define  new  measures  for 
hypertext  that  describe  characteristics  relevant  to  user  performance.  This  research  agenda  should 
include  research  into  these  areas: 

Evaluating  "hypertextability."  While  there  are  informal  guidelines  for  determining 
whether  a  particular  document  or  document  collection  is  suitable  for  conversion  to  hypertext, 
more  reliable  and  objective  measures  are  needed.  "Hypertextability"  can  potentially  be 
characterized  by  aspects  of  the  logical  structure  of  a  document,  such  as  the  number,  size,  and 
relationships  of  the  information  units. 

Validation  of  hypertext  conversion.  Measures  of  hypertextability  will  also  be 
invaluable  in  hypertext  projects  for  estimating  the  resources  required  and  estimating  schedules. 
Corresponding  methods  and  tools  for  measuring  the  "amount  of  hypertext"  that  has  been 
successfully  converted  should  follow;  perhaps  hypertext  sets  of  Hnks  can  be  evaluated  using 
analogues  to  the  familiar  ideas  of  "precision"  and  "recaU"  in  information  retrieval. 


-34- 


Measuring  hypertext  "readability."  Readability  formulas  for  ordinary  text  based  on 
sentence  length,  word  length,  or  other  characteristics  have  been  a  continuing  subject  of  research 
[8].  Hypertext  extensions  to  readability  metrics  might  include  measures  of  the  "goodness"  of 
links  based  on  similarity  between  linked  units.  Readability  measures  for  alternative  hypertext 
designs  for  the  same  text  will  go  far  toward  making  hypertext  design  an  engineering  discipline. 

A  final  research  area  identified  by  the  working  group  where  progress  will  immediately 
benefit  users  involves  intellectual  property  issues  for  hypertext  and  hypermedia.  The  rash  of 
"look  and  feel"  copyright  infringement  lawsuits  and  similar  claims  for  software  patents  confront 
software  designers  and  developers  with  chaos,  uncertainty,  and  legal  action  [10].  But  as  unclear 
as  the  situation  is  for  software  in  general,  the  novel  character  of  hypertext  and  hypermedia 
software  raises  still  more  complexities  for  intellectual  property  law.  For  example,  if  copyright 
law  has  different  rules  for  "literary  works,"  "audiovisual  works,"  "sound  recordings,"  and 
"pictorial  works,"  into  what  legal  category  does  an  interactive  hypermedia  encyclopedia  or  a 
talking  book  fall?  Are  new  links  or  notes  in  a  hypertext  system  considered  "derivative  works" 
under  copyright  law?  These  and  other  issues  are  not  just  legal  curiosities  ~  they  will  have 
considerable  impact  on  the  legal  protection  available  and  hence  the  economic  viability  of 
hypermedia  systems. 

REFERENCES 

[1]  Association  for  Computing  Machinery.  Hypertext  '87  Proceedings.  ACM:  New  York,  1987. 

[2]  Association  for  Computing  Machinery.  Hypertext  '89  Proceedings.  ACM:  New  York,  1989. 

[3]  Department  of  Defense.  Computer-aided  Acquisition  and  Logistic  Support.  Office  of  the 
Secretary  of  Defense  CALS  Office,  The  Pentagon,  Room  2B322,  Washington,  D.C. 
20301. 

[4]  Guttag,  J.  Abstract  data  types  and  the  development  of  data  structures.  Communications  of  the 
ACM,  20(6),  June  1977. 

[5]  Halasz,  F.,  and  Schwartz,  M.  The  Dexter  hypertext  reference  model.  Proceedings  of  the  NIST 
Hypertext  Standardization  Workshop,  Gaithersburg,  MD,  January  16-18,  1990. 

[6]  Hypermedia.  1(1),  1989. 

[7]  International  Organization  for  Standardization.  Standard  Generalized  Markup  Language, 
ISO  8879-1986. 

[8]  Klare,  G.  Assessing  readability.  Reading  Research  Quarterly,  1974-1975,  10,  62-102. 

[9]  McAleese,  R.  (Ed.).  Hypertext:  Theory  into  practice.  Blackwell  Scientific,  1989. 

[10]  Samuelson,  P.  Protecting  user  interfaces  through  copyright:  The  debate.  Proceedings  of  the 
ACM  Conference  on  Computer-Human  Interaction  -  CHI  '89,  97-103. 


PAPERS 


This  section  of  the  proceedings  contains  the  twelve  contributed  papers  which  were 
accepted  for  publication  and  featured  during  the  plenary  session  on  the  opening  day  of  the 
workshop.  It  also  contains  the  two  papers  which  the  interchange  group  recommended  be 
added. 


-37- 


Hypertext  Interchange  Format 
—  Discussion  and  Format  Specification  — 
DRAFT  1.3.4 
jeremy  bomstein 
victor  riley 


The  Hypertext  interchange  format  described  here  is  based  on  the  work 
of  the  Dexter  group,  an  industry  coaUtion  of  hypertext  researchers  interested 
in  a  standard  for  hypertext  data  exchange.  This  paper  describes  the  result  of  a 
collaboration  towards  this  end  between  Jeremy  Bornstein  and  Frank  Halasz, 
with  significant  input  from  other  members  of  the  Dexter  group,  most  notably 
Tim  Oren.  The  work  took  place  during  the  summer  of  1989,  and  a 
demonstration  is  planned  for  the  Hypertext  '89  conference  in  November  of 
1989. 


backgroimd  and  rationale 

The  number  of  hypertext  platforms  is  increasing,  not  decreasing. 
Although  this  development  will  most  likely  settle  down  to  a  stable  state,  it  is 
almost  certain  that  no  one  platform  will  dominate  the  hypertext  world  to  the 
extent  that  nobody  at  all  will  use  an  incompatible  platform.  Nevertheless, 
large  bodies  of  hypertext  data  are  being  developed  in  systems  which  will 
either  die  or  evolve.  An  interchange  format  allows  users  on  separate  systems 
to  share  their  data,  thus  eliminating  the  need  to  acquire,  learn,  and  use  a  new 
hypertext  system  only  to  access  that  system's  data. 

Of  course,  in  order  to  propose  a  reasonable  interchange  format,  the 
structure  of  the  data  must  first  be  determined.  As  it  happens,  with  regard  to 
hypertext  this  is  by  no  means  a  closed  issue.  The  Dexter  group  made  the 
decision  to  describe  a  format  which  would  be  able  to  include  everyone's 
definition  of  hypertext  and  thereby  short-circuit  "rathole"  debates  about  the 
nature  of  hypertext,  instead  focusing  effort  on  the  structure  of  a  given 
system's  hypertext.  The  framework,  described  below,  attempts  to  be  an 
inclusive  definition  rather  than  an  exclusive  one. 


-39- 


generalities 

The  format  is  an  ASCII  format,  as  opposed  to  a  binary  format. 
Conversion  to  a  binary  format  is  possible  if  desired,  but  a  text  format  is  much 
easier  when  the  definition  of  the  format  is  still  evolving. 

The  appearance  of  the  format  is  similar  to  that  of  SGML^:  there  are  tags 
marking  the  beginning  of  a  hierarchical  section  and  tags  marking  the  end 
("begin-tags"  and  "end-tags");  the  end-tag  corresponding  to  a  given  begin-tag 
has  a  backslash  ("\")  in  front  of  the  name  for  the  begin-tag.  Tags  appear 
between  greater-than  and  less-than  signs  ("<"  and  ">");  if  the  greater-than 
sign  appears  in  the  data,  it  is  doubled  ("«").  The  order  of  the  children  of  a 
given  tag  is  irrelevant^. 

Tags  which  are  not  understood  by  a  parser  are  guaranteed  to  be  ignored 
by  that  parser.  In  other  words,  if  a  particular  system  exports  information 
which  no  other  system  understands  (yet),  then  this  will  not  cause  another 
parser  to  crash,  but  merely  render  an  incomplete  version  of  the  document. 

The  characters  A-Z,  a-z,  1-9,  and  the  underscore  ("_")  are  the  only  valid 
characters  which  may  be  used  in  the  name  of  a  tag.  Case  is  not  significant.  So 
far,  the  agreed-upon  conventions  are  that  tags  begin  with  a  lower  case  letter 
and  that  words  after  the  first  are  marked  by  capitalization  of  the  initial  letter. 
For  example,  "thisHasFourWords"  is  a  tag  name  which  adheres  to  these 
conventions. 

Whitespace,  when  it  appears  outside  of  the  data  belonging  to  a  bottom- 
level  tag,  is  not  significant.  Often  in  examples,  a  single  space  character  is 
added  after  bottom  level  start-tags  and  before  the  corresponding  end-tags,  but 
this  whitespace  is  not  in  the  actual  export  files.  The  indentation  which 
appears  in  examples  is  also  not  part  of  the  format,  but  it  should  not  cause  an 
interchange-format  parser  to  fail. 

Since  many  references  in  a  hypertext  environment  will  take  place 
across  "document"  boundaries,  it  is  necessary  to  be  able  to  reference  many 
objects  from  a  global  standpoint.  In  order  to  make  this  independent  of  file 
name  and  directory  position,  global  IDs  are  used.  So  far,  the  numbers  are  64 
bit  numbers  which  may  be  chosen  by  any  method,  preferably  including  at 
least  some  random  bits.  Eventually  this  may  be  changed  in  favor  of  some 
method  which  better  ensures  uniqueness  of  each  identifier. 

specifics 


^SGML  ~  Standard  Generalized  Markup  Language 
^That  is,  the  following  two  expressions  are  equivalent: 

•  <foo>  <bar>  128  <\bar> 

<baz>  256  <\baz>  <\foo> 

•  <foo>  <baz>  256  <\baz> 

<bar>  128  <\bar>  <\foo> 


-40- 


This  section  is  a  rather  humorless  and  redundant  description  of  the 
data  format.  It  might  be  more  efficient  to  read  the  sample  file  first  and  then 
refer  below  for  confirmation  and  clarification  of  your  understanding.  The 
description  which  follows  is  hierarchical,  as  is  the  interchange  format  itself. 

<DOCUMENT> 

The  outermost  tag  in  a  HIP-format  document  is  the  <DOCUMENT> 
tag.  The  <DOCUMENT>  tag  has  four  possible  types  of  children:  the 
<HEADER>  tag,  <NODE>  tags,  <LINK>  tags,  and  <COMPOSITE>  tags. 
<HEADER> 

The  <HEADER>  tag  contains  relevant  information  about  the 
document  as  a  document:  the  name,  the  unique  id,  which 
system  it  was  exported  from  and  on  what  date. 
<NAME> 

This  is  the  name  of  the  document  in  the  originating 
system.  The  name  is  primarily  for  display  to  the  user,  but 
it  is  possible  that  it  could  be  used  in  trying  to  resolve  links 
as  well. 

<ID> 

This  is  the  unique  id  of  the  document,  following  the  rules 
for  ids  given  above. 
<EXPORTED> 

This  tag  contains  information  about  the  originating 
system  and  when  the  document  was  exported  from  that 
system. 
<FROM> 

This  is  the  name  of  the  originating  system. 
<DATE> 

This  is  the  date  on  which  the  document  was 
exported.  A  standard  format  for  the  date  has  not 
been  agreed  upon. 


-41- 


<ACCESS> 

These  are  the  access  rights  for  the  document  set.  In  the 
case  of  Intermedia  this  is  the  web,  for  NoteCards  this  is  the 
NoteFile,  for  HyperCard  this  is  the  stack.  No  format  has 
been  agreed  upon. 
<CREATION> 

The  <CREATION>  tag  tells  the  time  of  creation  and  the 

creator  for  the  document. 

<BY> 

This  is  the  creation  author. 
<DATE> 

This  is  the  date  which  the  document  was  created. 
<MODIFIED> 

The  <MODIFIED>  tag  tells  the  time  of  modification  and 
the  modifier  for  the  document.  A  set  of  these  can  tell 
history  for  changes. 
<BY> 

This  is  the  modifier  author. 
<DATE> 

This  is  the  date  which  the  document  was  last 
modified. 

<NODE> 

The  <NODE>  tags  in  a  document  function  as  the  wrappers  for 
the  text/ graphics /&c.  A  <NODE>  has  several  parts: 
<USE> 

This  tag  is  used  to  specify  the  location  to  the  contents  of 
the  NODE.  If  two  <DOCUMENTS>  share  the  same 
<NODE>,  the  <USE>  tag  is  used  to  specify  the  location  of 
the  shared  data. 
<NAME> 

This  is  the  name  of  the  node  in  the  originating  system. 
The  name  is  primarily  for  display  to  the  user. 

<ID> 

This  is  the  unique  id  of  the  <NODE>  (see  above). 


-42- 


<ACCESS> 

These  are  the  access  rights  for  the  node. 
<CREATION> 

The  <CREATION>  tag  tells  the  time  of  creation  and  the 

creator  for  the  node. 

<BY> 

This  is  the  creation  author. 
<DATE> 

This  is  the  date  which  the  node  was  created. 
<MODIFIED> 

The  <MODIFIED>  tag  contains  information  about  who 
made  the  last  modification  to  the  NODE,  and  when  the 
modification  was  made.  A  set  of  these  can  tell  history  for 
changes. 
<BY> 

This  is  the  userid  (or  other  identifying  information) 
of  the  last  person  to  modify  the  NC3dE. 
<DATE> 

This  is  the  date  which  the  node  was  last  modified. 

<DATA> 

The  <DATA>  tag  contains  the  <NODE>'s  low-level  data 
(text  or  a  picture,  for  example).  If  the  <USE>  tag  is  used, 
this  should  be  NULL. 
<runTiineStuff> 

The  <runTimeStuff>  tag  contains  information  about  how 
the  <DATA>  should  be  displayed;  it  is  currently  the  tag 
undergoing  the  most  revision.  It  is  expected  that  much  of 
the  information  within  it,  such  as  font  name,  will  often  be 
unusable  in  the  imported-to  system.  Within  the 
<RunTimeStuff>  tag,  the  five  tags  below  are  the  only  ones 
currently  defined.  The  last  three  will  most  likely  be 
uninterpreted  by  any  system  besides  HyperCard. 
<FRAME> 

The  position  of  a  NODE  with  respect  to  its  parent^  is 
described  by  the  <FRAME>  tag.  If  the  <FRAME> 
tag  is  absent,  then  the  parent  <NODE>  is  considered 
to  be  "immediately  subsequent"  to  the  previous 
<NODE>.  This  would  be  the  case  for  multiple 
<NODE>s  in  a  creamy  hypertext  system  such  as 
Notecards  or  InterMedia.  Otherwise,  the  following 
two  tags  determine  the  frame: 
<SIZE> 

This  is  the  size  (x,y)  of  the  node. 
<LOCATION> 

This  represents  the  offset  (x,y)  between  the 
parent's  origin  and  the  node's  origin.  If  not 


■^The  parent  may  be  a  <GOMPOSITE>  node  or  null. 


-43- 


present,  it  is  undefined  and  the  importing 
system  is  free  to  set  it  arbitrarily. 

<fontSpec> 

The  <fontSpec>  contains  information  about  the 

font  of  the  data. 

<NAME> 

This  tag  contains  the  name  of  the  font. 
<SIZE> 

This  tag  contains  the  point  size  of  the  font. 
<STYLE> 

This  tag  contains  any  style  modifications  to 
the  font:  i.e.,  bold,  italic,  underline,  &c. 
<JUSTIFY> 

This  tag  contains  the  justification  rule  for  the 
text:  left,  center,  or  right. 

<lockText> 

This  tag  is  "true"  if  the  user  is  allowed  to  modify 
the  text  of  the  item,  and  "false"  otherwise. 
<STYLE> 

This  tag,  probably  only  interpreted  by  HyperCard, 
describes  the  frame  for  the  <NODE>'s  <DATA>. 
<originalType> 

This  tag,  also  probably  only  interpreted  by 
HyperCard,  contains  "button"  or  "field,"  depending 
on  the  original  type  of  the  object. 
<ANCHOR> 

There  may  be  several  <ANCHOR>  tags  within  a  given 
<NODE>.  The  anchor  tags  contain  information  about  all 
anchors  present  within  the  <NODE>'s  <DATA>. 
<NAME> 

This  is  the  name  of  the  anchor  in  the  originating 
system.  The  name  is  primarily  for  display  to  the 

user. 

<ID> 

This  is  the  unique  id  of  the  anchor  and  must  be 
present. 


-44- 


<CREATION> 

The  <CREATION>  tag  tells  the  time  of  creation  and 

the  creator  for  the  anchor. 

<BY> 

This  is  the  creation  author. 
<DATE> 

This  is  the  date  which  the  anchor  was 
created. 
<MODIFIED> 

The  <MODIFIED>  tag  contains  information  about 
who  made  the  last  modification  to  the  ANCHOR, 
and  when  the  modification  was  made.  A  set  of 
these  can  tell  history  for  changes. 
<BY> 

This  is  the  userid  (or  other  identifying 
information)  of  the  last  person  to  modify  the 
ANCHOR. 
<DATE> 

This  is  the  date  which  the  anchor  was  last 
modified. 

<LOCATION> 

This  is  the  offset  in  bytes  (O  is  the  position  before 
the  first  character)  of  the  anchor  texc.  If  the 
<LOCATION>  is  a  pair  of  numbers  separated  by  a 
comma  (or  a  triple  for  3-D  space),  this  describes  the 
text  span  already  in  Lhe  <DATA>.  If  the 
<LOCATION>  is  absent,  the  whole  <DATA>  is  the 
relevant  text. 

<TEXT> 

This  is  the  text  which  the  anchor  is  attached  to.  If 
the  <LOCATION>  tag  is  a  single  number  (i.e.,  no 
comma)  then  the  text  is  inserted  at  that  position. 
Otherwise,  the  text  need  not  be  specified. 
<runTimeStuff> 

The  <runTimeStuff>  tag  contains  information 
about  how  the  <ANCHOR>  should  be  displayed;  it 
is  currently  undergoing  revision. 
<VIEW> 

The  <VIEW>  tag  contains  information  about 
how  the  <ANCHOR>  could  be  viewed.  This 
also  specifies  whether  the  <ANCHOR>  is  a 
2D  or  3D  view  or  either.  Right  now,  this  is 
application  specific. 
<OBJECT> 

The  <OBJECT>  tag  specifies  the  objects  the 
<ANCHOR>  is  attached  to.  This  covers 
multiple  spans  of  text,  or  multiple  graphical 
objects.  Right  now  this  is  application  specific. 

<LINK> 


-45- 


A  <LENrK>  holds  all  the  information  about  a  single  bidirectional 
link.  This  may  be  expanded  in  the  future  to  describe  multi- 
headed  and  multi-tailed  links. 
<NAME> 

This  is  the  name  of  the  link  in  the  originating  system. 
The  name  is  primarily  for  display  to  the  user. 

<ID> 

This  is  the  unique  ID  of  the  link  itself. 
<sourceNodeId> 

This  is  the  ID  of  the  node  associated  with  the  start  of  the 
link. 

<sourceAnchorId> 

This  is  the  ID  of  the  anchor  (within  the  source  NODE) 

from  which  the  link  originates.  If  unspecified,  the  link  is 

from  the  whole  NODE. 
<destinationNodeId> 

This  is  the  ID  of  the  node  associated  with  the  end  of  the 

link. 

<destinationAnchorId> 

This  is  the  ID  of  the  anchor  (within  the  destination 

NODE)  to  which  the  link  is  bound.  If  unspecified,  the  link 

destination  is  the  whole  NODE. 
<CREATION> 

The  <CREATION>  tag  tells  the  time  of  creation  and  the 

creator  for  the  link. 
.  <BY> 

This  is  the  creation  author. 
<DATE> 

This  is  the  date  which  the  link  was  created. 
<MODIFIED> 

The  <MODIFIED>  tag  contains  information  about  who 
made  the  last  modification  to  the  LINK,  and  when  the 
modification  was  made.  A  set  of  these  can  tell  history  for 
changes. 
<BY> 

This  is  the  userid  (or  other  identifying  information) 
of  the  last  person  to  modify  the  LINK. 
<DATE> 

This  is  the  date  which  the  link  was  last  modified. 

<TYPE> 

This  is  a  string  which  describes  the  type  of  link;  some 
examples:  "Explanation,"  "Next,"  "Annotation." 
<COMPOSITE> 

A  <COMPOSITE>  tag  is  the  framework  within  which  frame- 
based  systems  such  as  HyperCard  and  KMS  represent 
cards/frames.  It  contains  an  <id>,  one  or  more  <NODE>s,  and  a 
<runTimeStuff>. 
<ID> 

This  is  the  <COMPOSITE>'s  unique  ID. 


-46- 


<mnTimeStuff> 

So  far,  the  only  <runTimeStuff>  defined  for  a 
<COMPOSITE>  is  the  <FRAME>. 
<FRAME> 

The  <FRAME>  represents  the  <COMPOSITES>'s 

size  and  relation  to  its  parent. 

<SIZE> 

This  is  the  size  (x,y)  of  the  connposite. 
<LOCATION> 

This  represents  the  offset  (x,y)  between  the 
parent's  origin  and  the  composite's  origin.  If 
not  present,  it  is  undefined  and  the 
importing  system  is  free  to  set  it  arbitrarily. 

<NODE> 

This  is  the  meat  of  the  composite.  See  above  for  a 
description  of  this  data  structure. 


-47- 


Standards  for  hypertext  source  files:  the  experience  of  UNIX  Guide 


P.J.  Brown 

Computing  Laboratory 
The  University 
Canterbury 
Kent,  CT2  7NF 
England 


-49- 


In  real-world  applications,  it  is  rare  that  a  hypertext  system  provides  a  complete  solution.  Instead 
the  solution  normally  comes  from  a  combination  of  a  hypertext  system  with  other  tools.  Thus,  as 
Meyrowitz  (1987)  has  argued  in  his  powerful  position  paper  "The  missing  link:  why  we're  all 
doing  hypertext  wrong",  one  of  the  most  desirable  attributes  of  a  hypertext  system  is  diat  it 
should  fit  easily  into  its  environment,  and  allow  a  close  interaction  with  other  tools  in  that 
environment. 

There  is  now  a  movement  towards  standardisation  in  hypertext  systems,  in  particular  a  proposal 
that  source  files  for  hypertext  systems  should  follow  a  standard  form  so  that  material  can  be 
interchanged  between  different  systems.  The  market  forces  pushing  this  standardisation  effort  are 
obvious,  but  we  must  ensure  that  new  standards  do  not  detract  from  the  interaction  between 
hypertext  systems  and  other  tools.  At  an  extreme,  a  standard  that  made  it  easy  for  a  hypertext 
system  to  exchange  files  with  other  hypertext  systems  but  hard  to  exchange  with  anything  else 
would  be  a  disaster. 

Do  we  use  text-files? 

Choosing  a  file  format  for  hypertext  systems  is  similar  to  choosing  a  file  format  for  word- 
processing  systems.  Indeed  many  hypertext  systems  support  a  good  repertoire  of  word-processing 
operations.  Hypertext  systems  have  the  added  needs  of  representing  hypertext  constructs  and 
links.  Hopefully  any  standard  will  encompass  all  documents,  irrespective  of  whether  they  are 
created  from  word-processing  or  hypertext.  For  hypermedia  systems,  similar  considerations  apply 
to  the  other  media,  but  this  paper  concentrates  mainly  on  text. 

A  basic  choice  is  whether  files  should  be  a  text-file.  By  a  text-file  we  mean  a  linear  sequence  of 
text  with  embedded  mark-up  but  with  no  embellishments  such  as  file-headers,  associated  tables, 
embedded  pointers,  etc. 

This  paper  argues  the  advantages  of  text-files.  The  argument  is  based  on  experience  with  the 
UNIX  implementation  of  Guide,  which  uses  a  text-file  format.  Most  of  the  material  is  concerned 
with  nitty-gritty  practical  experience  rather  than  with  any  underlying  theory,  but  standards  cannot 
ignore  these  practical  aspects.  We  shall  start  by  emphasising  the  properties  of  UNIX  Guide  that 
influence  its  file  format. 

UNIX  Guide 

A  central  aim  of  the  UNIX  implementation  of  the  Guide  hypertext  system  is  that  it  should  fit  well 
into  a  UNIX  environment  (Brown,  1989).  Indeed  it  is  this  facet,  more  than  anything  else,  that  has 
caused  UNIX  Guide  to  be  different  from  the  implementation  of  Guide  marketed  by  Office 
Workstations  Ltd  (OWL)  which  runs  on  Macintoshes  and  PCs.  OWL  Guide  successfully  fits  into 
its  environment,  which  is  very  different  from  UNIX  and  has  a  strong  house-style  that  pervades 
most  of  the  software  that  runs  in  that  environment. 

UNIX  Guide  —  and  henceforth  all  references  to  Guide  should  be  taken  as  UNIX  Guide  —  tries  to 
follow  the  original  UNIX  'Small  is  beautiful'  philosophy,  though  this  philosophy  has  perhaps 
been  weakened  over  the  years  to  the  less  catchy  'Medium-sized  is  beautiful'.  Guide  cannot  hope 
to  provide  all  the  facilities  that  users  may  want.  Instead  it  should  be  good  at  one  thing,  hypertext, 
and  use  other  tools  to  provide  functions  that  they  are  good  at. 

Characteristic  features 

Every  hypertext  system  has  some  characteristic  features  that  set  it  apart  from  the  herd.  In  the  case 
of  Guide  there  are  three  such  features:  UNIX  orientation,  which  we  have  just  discussed,  late 
binding  and  the  scroll  model. 


-50- 


Guide's  late  binding  philosophy  is  that  fixing  of  hypertext  links  should  be  delayed  to  the  last 
possible  moment;  this  is  normally  at  run-time  when  the  link  is  selected  for  the  first  time.  Late 
binding  has  a  number  of  benefits,  arising  from  the  dynamic  nature  of  links. 

The  Guide  author  specifies  a  link  by  a  symbolic  name  (e.g.  'Lesser-spotted  woodpecker').  If  the 
link  goes  outside  the  current  file  a  filename  is  appended  to  the  symbolic  name  (e.g.  in  /x/y/z'). 
The  destination  of  a  link  is  a  Guide  'definition'  with  the  same  symbolic  name  as  the  link.  When 
links  are  saved  in  Guide  source  files  they  follow  this  symbolic  form  —  they  are  just  a  sequence  of 
characters  attached  to  the  button-name  that  is  the  source  of  the  link,  and  only  at  run-time  do  they 
cause  a  link  to  be  forged  (by  searching  for  a  definition  that  matches  the  given  name).  Late  binding 
is  therefore  a  force  that  makes  source  files  simpler  and  flatter. 

The  third  characteristic  feature  of  Guide  is  its  scroll  model.  A  Guide  document  is  a  continuous 
scroll,  and  when  buttons  are  selected  they  are  replaced  in-lLne  by  the  corresponding  button- 
replacement,  thus  causing  the  scroll  to  grow  and  shrink  as  buttons  are  selected/deselected. 

Groups  of  buttons  can  be  combined  into  larger  units,  called  enquiries.  In  Conklin's  (1987) 
terminology  an  enquiry  is  a  region,  which  is  replaced  if  any  button  within  the  region  is  selected. 
In  page-based  systems  that  have  a  single  current  page,  e.g.  HyperCard,  the  region  to  be  replaced 
is  always  the  whole  current  page.  Enquiries  offer  more  flexibility:  in  particular,  at  one  extreme 
they  can  be  made  to  encompass  the  entire  current  document.  If  this  is  done.  Guide, 
notwithstanding  its  underlying  scroll  model,  can  be  used  to  simulate  these  page -based  hypertext 
systems.  (See  Brown  (1990)  for  a  discussion  of  a  large  application  that  takes  advantage  of  this.) 
At  another  extreme  the  region  of  replacement  can  be  made  null:  everything  remains;  if,  in 
addition,  a  button  is  made  to  throw  its  replacement  up  in  a  new  window  (as  Guide  'action-buttons 
can  be  made  to  do)  instead  of  in  place  of  the  original  button,  then  the  end  result  has  the  flavour  of 
NoteCards.  Overall,  therefore,  the  scroll  model  is  not  fundamentally  different  from  a  page-based 
one. 

Nevertheless  the  scroll  model,  with  in-line  replacement  the  norm,  has  influenced  the  source  file 
design.  For  the  simplest  type  of  button,  which  has  a  fixed  replacement  that  is  associated  with  that 
button  and  no  other,  the  button-replacement  comes  immediately  after  the  button-name  in  the 
Guide  source  file.  This  simplest  type  is  button  is  also  generally  the  commonest,  since  it  is  used  in 
hierarchical  expansions. 

Guide  source  files 

Having  covered  Guide's  characteristics  we  can  now  describe  its  source  file  format,  and  the 
advantages  that  come  from  using  such  a  format. 

As  we  have  said,  the  file  format  is  that  of  a  text-file:  a  sequence  of  text  and  graphics  with 
embedded  mark-up.  The  mark-up  simply  shows  where  Guide  constructions  (e.g.  buttons, 
replacements,  enquiries,  'ghosts'  —  Guide  comments)  begin  and  end.  All  the  necessary 
information  is  carried  by  this  mark-up:  there  is  no  file-header  and  there  are  no  associated  tables, 
etc. 

The  mark-up  follows  the  format  of  trojf  requests.  For  example,  a  button-name  'Lesser-spotted 
woodpecker'  would  be  represented  as 

.  Bu  button-attributes 
Lesser-spotted  woodpecker 
.bU 

Thus  die  Bu  and  bU  requests  mark  the  beginning  and  end  of  a  button  name,  and  the  Bu  request  has 
as  its  argument  a  description  of  the  button's  attributes.  (For  better  or  for  worse,  attributes  do  not 
figure  sfi-ongly  in  Guide  and  the  Bu  request  is,  in  fact,  one  of  the  few  Guide  requests  that  has 
attributes.) 


-51- 


The  purpose  of  this  paper  is  not,  of  course,  to  propose  fro^  format  as  a  standard.  As  far  as  Guide 
itself  is  concerned  it  would  be  equally  easy  to  replace  the  troff  syntax  with  any  other  syntax  that 
had  mark-up  embedded  in  the  text,  e.g.  our  previous  example  could  have  been  in  the  SGML  (ISO, 
1986)  form: 

<  Button  ...  >  Lesser-spotted  woodpecker  < \Button  > 

However,  given  the  need  to  use  other  UNIX  tools,  the  use  of  troff  syntax,  which  is  a  UNIX 
standard,  has  certain  advantages.  For  example: 

•  spell,  the  UNIX  spelling  checker,  can  be  used  on  Guide  files  without  any  adjustment. 
(It  automatically  strips  off  rroj^^mark-up  by  using  the  deroffniility.) 

•  if  Guide  files  are  to  be  formatted  and  printed  on  paper,  troff  can  do  the  job.  For 
example  the  Bu  request  can  be  made  a  macro  which,  inter  alia,  switches  to  bold-face  so 
that  button-names  come  out  in  bold.  (The  names  of  Guide  requests  have  been 
deliberately  chosen  not  to  clash  with  other  r?7?^ requests.) 

These  UNIX -dependent  advantages  of  Guide's  mark-up  should  not,  however,  be  over- 
emphasized, and  if  SGML-based  tools  had  been  readily  available  SGML  format  would  have  been 
a  better  choice. 

Readability 

The  majority  of  Guide  users  are  unaware  of  how  its  source  files  are  stored.  However  some  authors 
do  need  to  look  at  or  to  generate  source  files,  and  for  them  it  is  a  huge  advantage  that  the  files  are 
fairly  readily  understood  by  humans.  Indeed  the  very  first  Guide  implementation  (1984-5)  had  a 
file  format  involving  esoteric  binary  codes,  and  perhaps  the  greatest  step  forward  in  Guide's 
development  has  been  the  banishing  of  this  mumbo-jumbo.  Sample  benefits  of  the  readable  form 
are: 

•  it  can  be  edited  using  speciahst  editors.  Although  Guide  offers  editing,  this  is  not  its 
forte;  elaborate  editing,  e.g.  global  replacement  of  a  pattern,  can  be  done  by  a  tool  that 
is  specially  designed  for  such  tasks. 

•  it  makes  conversion  programs  easier  to  write  and  debug,  a  point  we  discuss  later. 
Other  media 

Although  this  paper  concentrates  on  text,  since  we  believe  it  will  predominate  in  most  hypertext 
applications  for  the  foreseeable  future,  it  is  not  sensible  to  ignore  other  media.  They  can  be  either: 

(a)  stored  in  separate  files,  whose  names  are  referenced  in  the  main  text-file.  These 
separate  files  would  hopefully  be  represented  in  the  appropriate  standard  form  for 
the  media. 

or  (b)  embedded  in  the  form  of  comments  in  the  text-file.  Often  the  content  of  these 
comments  will  appear  as  arbitrary  binary  codes,  sanitized  if  it  is  necessary  to  avoid 
'difficult'  codes  such  as  end-of-file  and  end-of-line. 

UNIX  Guide  offers  both.  If  the  second  approach  is  used  a  bit-map  picture  is  represented  as: 


-52- 


.Pi 

.  \"  bytes  representing  binary  encoding 
A"  bytes  representing  binary  encoding 


.pi 

Each  line  of  the  binary  encoding  is  made  to  appear  as  a  troff  comment.  This  is  important,  as  it 
causes  utilities  such  as  spell  to  ignore  these  lines;  otherwise  there  could  be  spurious  reports  of 
spelling  errors. 

In  order  to  create  the  encoding  of  a  picture,  Guide  has  to  capmre  the  raw  picture  in  the  first  place. 
(The  raw  picture  will  typically  have  come  from  a  drawing  program  or  a  scanner.)  Like  most  other 
software,  Guide  tries  to  avoid  input  modes  ('This  is  a  picture',  'This  is  a  text  file').  Input  modes 
can  be  avoided  if  files  have  a  type  associated  with  them.  UNIX  has  a  somewhat  basic  —  unkind 
people  would  say  crude  —  mechanism  for  attaching  a  data  type  to  a  file.  This  is  the  'magic 
number'.  It  helps  Guide  avoid  input  modes  though  it  becomes  difficult  if  materia!  comes  in 
through  a  pipe  rather  than  direct  from  a  file.  Overall  a  standard  could  not  assume  that  every  file 
system  provides  a  satisfactory  mechanism  for  attaching  a  data  type  of  a  file.  Hence  if  source  files 
are  represented  in  a  wide  variety  of  forms,  corresponding  to  different  media  standards,  the  user 
will  sometimes  be  forced  into  the  use  of  different  input  modes. 

Aims  of  standards 

It  is  worth  pausing  at  this  point  to  consider  the  purpose  of  hypertext  standards.  Three  important 
aims  of  hypertext  standards  should  be: 

(1)  to  allow  import/export  of  documents,  or  more  generally  to  allow  sharing  of  documents 
with  other  software. 

(2)  to  allow  exchange  of  documents  with  other  hypertext  systems. 

(3)  to  allow  existing  tools  to  be  applied  to  standard  documents. 

The  last  of  these  is  often  overlooked,  but  if  there  are  no  tools  associated  with  a  standard  the 
standard  will  be  a  standard  that  no-one  uses  —  a  bitter  lesson  that  many  have  learned.  In  most 
environments  (and  especially  in  UNIX)  the  vast  majority  of  existing  tools  use  a  linear  textual 
format.  This  may  be  a  sad  commentary  on  the  state  of  the  world,  but  it  is  the  reality.  Hence 
choice  of  a  text-file  fonnat  as  a  standard  has  big  advantages. 

One  can  argue  on  the  relative  importance  of  (1)  to  (3)  above.  Personally  we  rate  (1)  and  (3)  equal, 
with  (2)  far  behind.  We  shall  now  discuss  (1)  further. 

There  are  two  sub-cases  of  (1).  Firstly  there  is  the  import/export  case  where  material  produced  by 
another  tool  is  converted  to  hypertext  form  or  the  hypertext  form  is  converted  for  use  by  another 
tool.  The  other  tool  may  be  a  word-processor,  a  database,  a  programming  language  compiler,  a 
drawing  tool,  etc.  Secondly  there  is  the  Utopia  which  the  standard  envisages:  all  material  shares 
the  same  format  and  no  conversion  is  necessary  —  though  several  problems  remain,  as  we  shall 
see  later. 

Conversion  may  be  done  in  advance  or  on-the-fly.  The  latter  is,  of  course,  preferred  if  conversion 
is  a  fast  process,  since  it  does  not  involve  keeping  two  separate  documents  up  to  date.  Conversion 
is  normally  a  dreary  and  unsatisfactory  process,  but  there  are  three  ways  in  which  the  hypertext 
file  format  can  help: 

•      a  simple  textual  format  facihtates  conversion. 


-53- 


•  it  helps  if  hierarchical  buttons  have  their  replacement  immediately  following.  For 
example  it  then  requires  only  a  trivial  effort,  when  converting  a  word-processor  file,  to 
map  section  headings  into  button-names  and  the  body  of  the  section  into  the  button's 
replacement. 

•  a  format  that  is  readable  by  humans  aids  the  debugging  of  conversion  utilities.  (Sadly, 
conversion  utilities,  because  of  their  ad  hoc  nature,  tend  to  take  a  long  time  to  debug. 
Each  new  source  document  brings  a  new  crop  of  problems.) 

Pipes 

If  conversion  is  performed  on-the-fly  the  UNIX  pipe  —  now  available,  in  one  form  or  another,  in 
most  operating  systems  —  is  a  convenient  way  for  transferring  data.  Hence  Guide  is  frequently 
used  as  a  component  of  a  pipe. 

Following  the  general  UNIX  philosophy  Guide  does  not  know  or  care  whether  its  input  comes 
from  a  source  file  or  a  pipe  and  the  same  format  applies  to  both. 

In  this  environment  the  following  characteristics  of  source  files  have  proved  valuable: 

•  source  files  are  text-files  —  again  this  advantage  comes  first:  most  piping  mechanisms 
are  based  on  the  stream-of -characters  model. 

•  a  text-file  containing  no  mark-up  at  all  is  a  valid  soiu-ce  file.  Such  material  (e.g.  the 
whole  or  part  of  existing  non-structured  files)  is  commonly  used  in  building  Guide 
documents  and  does  not,  therefore,  require  a  special  input  mode. 

•  a  concatenation  of  source  files  is  a  valid  source  file.  Moreover  a  soui'ce  file  can  be 
included  within  another.  Thus  a  utility  such  as  the  C  pre-processor  can  be  used  to 
build  the  Guide  input  from  a  combination  of  existing  source  files.  (These  may,  indeed, 
be  paranieterised  using  pre-processor  statements  such  as  define  and  ifdef.) 

Newlines 

A  small  issue  of  some  importance  is  the  treatment  of  newline  characters,  and  in  particular  whether 
they  should  be  hard  or  soft.  Since  newlines  are  hard  in  ordinary  text  files.  Guide  generally  treats 
newlines  as  hard.  However  a  newline  that  precedes  a  Guide  request  is  ignored.  (A  newline 
preceded  by  a  null  Guide  request  therefore  acts  as  a  soft  newline.  When  Guide  saves  a  file  it 
inserts  a  soft  newline  if  an  output  line  is  getting  too  long  —  very  long  lines  knock  out  many 
UNDC  utilities.)  Obviously,  when  material  is  imported  or  exported,  soft  newlines  and  other  soft 
mark-up  needs  to  be  stripped  out  before  transmission. 

Dynamic  interchange 

Ideally  a  hypertext  system  should  support  a  dynamic  interaction  with  its  environment.  Thus  data 
should  be  shared  with  other  programs  while  the  hypertext  system  is  running.  It  is  natural  that  the 
source  file  format  applies  to  such  data  as  well  as  to  data  that  is  pre-stored  in  source  files.  In  Guide, 
the  selecfion  of  a  button  can  cause  a  program  to  be  run,  and  the  output  from  that  program  serves  as 
the  replacement  of  the  button.  This  output  follows  the  normal  Guide  source  format;  usually  it  is  a 
sequence  of  ASCII  characters  without  any  mark-up.  Sometimes,  however,  the  output  may  involve 
hypertext  structure:  for  example  in  one  application,  a  button  launches  a  program  that  is  a  retrieval 
system.  The  program  searches  for  a  given  term  and  converts  the  hit  list  into  a  hypertext  structui"e 
that  makes  it  easy  for  the  user  to  examine  the  hits  rJiat  seem  most  relevant.  This  structure  is  duly 
displayed  by  the  hypertext  system.  In  another  application  a  button  runs  a  program  to  produce  a 
report  of  items  currently  in  stock,  and  this  output  is  produced  in  a  hierarchical  hypertext  format. 

The  issue  of  standardization  also  affects  the  programs  that  are  executed  within  hypertext  systems. 
Most  systems  contain  their  own  programming  language,  and  in  HyperCard  this  is  a  major  part  of 


-54- 


the  system.  However  experience  suggests  it  would  be  hopeless  to  expect  every  hypertext  system 
to  abandon  its  current  programming  laiiguage  and  adopt  a  new  standard  one. 

Saving 

The  'save'  operation  from  a  hypertext  system  may  involve: 

(1)  saving  what  is  seen. 

(2)  saving  what  is  seen,  together  with  the  hypertext  structure  behind  it. 

It  is  (2)  that  interests  us  here,  since  it  creates  a  hypertext  source  file.  This  output  file  need  not 
relate  directly  to  a  single  input  file:  at  one  extreme  it  could  have  resulted  from  loading  several 
input  (lies  and  editing  them;  at  the  other,  the  material  saved  could  be  a  small  fragment  of  an 
original  input  file. 

Cut-and-paste,  when  used  to  cut  from  the  hypertext  system,  is  a  special  case  of  saving.  Ideally 
both  (1)  and  (2)  above  should  be  offered,  though  Guide  cmrently  only  offers  (1).  Case  (2)  is 
useful  if  the  material  is  to  be  pasted  back  into  a  hypertext  document. 

Saving  may  go  directly  to  a  file  or  into  an  output  pipe. 

Saving  presents  no  problem  if  source  files  use  a  text-file  format.  If  the  source  format  involves 
file-headers  or  the  like,  it  requires  more  thought  and  perhaps  more  user  action,  particularly  if  the 
original  input  came  from  diverse  sources. 

Sharing  files 

EarUer  in  this  paper  we  wandered  in  the  anarchical  world  of  conversion  programs;  it  is  now  time 
to  move  on  to  the  relatively  Utopian  idea  of  sharing  information  so  that  an  identical  file  can  be 
processed  by  many  different  systems. 

Let  us  assume  that  two  programs  X  and  Y  share  the  same  file.  (X  and  Y  may  be  different 
hypertext  systems  or  one  or  other  of  them  may  be,  say,  a  word-processing  system.)  A  user  of  X 
may  load  the  file,  edit  it  and  then  save  it.  Cletu-iy  the  file  should  still  be  usable  by  Y. 

This  apparently  simple  requirement  requires  care.  Inevitably  there  will  be  some  operations  Y  can 
do,  but  X  cannot.  Assume  for  example  that  Y  can  display  text  in  different  point-sizes  but  X 
cannot.  If  a  file  contains  mark-up  indicating  a  change  of  point-size  X  must  preserve  this 
information  when  a  file  containing  point-size  changes  is  loaded  into  X,  edited  and  subsequently 
saved.  As  a  greater  challenge,  X  must  behave  sensibly  when  editing  involves  material  that 
contains  point-size  changes:  what  happens  if  half  of  a  siring  in  a  large  point-size  is  copied,  and  the 
instruction  to  increase  the  point-size  is  copied  but  the  corresponding  instruction  to  set  it  back  is 
not  copied? 

Guide  currently  makes  an  attempt  to  deal  with  these  issues.  It  has  an  experimental  system  for 
sharing  files  with  trojf.  If  a  rroff  file  is  loaded  into  Guide,  Guide  tries  to  take  account  of  mark-up 
it  can  handle,  e.g.  new  paragraphs;  other  mark-up.  such  as  change  of  point-size,  is  ignored. 
However  all  the  original  fro^  mark-up  is  loaded  into  Guide  in  the  form  of  'ghosts'  —  comments 
that  are  only  visible  to  Guide  authors,  not  to  Guide  readers.  When  a  Guide  file  is  saved,  these 
ghosts  are  converted  back  to  the  original  troff  maxk-up,  thus  re-creating  the  original  file.  Given 
that  Guide  authors  can  see  these  ghosts,  they  will,  hopefully,  be  aware  of  the  implications  of  the 
mark-up  when  they  perform  edits. 

On  the  other  side  of  the  sharing,  when  troff  is  using  the  file,  there  are  fewer  problems,  not  least 
because  trojf  has  no  save  operation.  It  is,  in  this  simation,  a  happy  property  of  troff  that  it 
completely  ignores  requests  it  caimot  recognise;  thus  Guide  mark-up  is  ignored. 

Overall  the  current  Guide  sharing  system  just  about  works,  but  could  profitably  be  replaced  by 
something  built  on  sounder  foundations. 


-55- 


Errors 

If  source  files  may  be  generated  by  conversion  tools,  editors,  etc.,  they  may  well  contain  errors. 
The  design  of  source  files  should  therefore  contain  enough  redundancy  for  such  errors  to  be 
detected.  The  design  should  also  bear  in  mind  that,  on  detecting  an  error,  the  hypertext  system 
should  have  sufficient  information  to  give  a  decent  error  message  and  stop  gracefully,  retaining  as 
much  of  the  source  file  as  possible. 

Abstractions  and  discipline 

The  focus  of  this  paper  has  largely  been  on  the  present  rather  nasty  world.  Ideally  standards 
should  look  to  the  future  as  well  as  covering  the  present. 

Current  usage  of  Guide  (and  doubtless  of  other  hypertext  systems  too)  has  shown  up  two 
deficiencies: 

(1 )  a  need  for  higher  level  abstractions  than  links,  which  are  gotos. 

(2)  a  need  for  each  application  to  evolve  a  hypertext  house-style  and  to  impose  this. 

The  two  needs  are  related:  many  aspects  of  a  house-style  can  be  imposed  by  designing  some 
special  abstractions  and  then  ensuring  that  authors  use  only  those  abstractions.  This  is  similar  to 
the  way  that  document  standards  such  as  ODA  (ISO,  1988)  and  SGML  impose  a  general 
document  architecture. 

The  ICL  Locator  project  (Meehan,  1987;  Brown,  1990),  one  of  the  biggest  current  Guide 
applications,  has  successfully  tackled  (1)  and  (2)  by  producing  a  preprocessing  tool  for  Guide  that 
helps  (and  constrains)  authors  to  produce  the  required  Locator  style.  However  preprocessors  are 
not  always  the  answer  for  the  same  reason  that  preprocessors  to  compilers  for  programming 
languages  are  not  always  the  answer.  In  the  latter  case  the  program  author,  when 
maintaining/debugging  a  program,  usually  needs  to  be  aware  of  its  intermediate  form  and  thus  the 
power  of  the  abstraction  that  the  preprocessor  provides  is  lost. 

Experience  also  shows  that  some  environments  want  discipline  and  some  want  freedom.  Tlius 
heavyweight  mechanisms  that  affect  everybody  need  to  be  avoided. 

Overall,  therefore,  it  is  desirable  that  soiu-ce  file  formats  contain  facilities  for  defining  or  imposing 
abstractions,  but  these  should  be  optional.  It  should  still  be  possible  for  draconian  managements 
to  enforce  their  requirements;  for  example,  currently  some  managements  do  not  release  the  real 
Guide  to  their  authors,  but  equate  'Guide'  to  a  UNIX  shell-script  which  loads  the  real  Guide  with 
certain  options  already  pre-set,  and  perhaps  with  some  of  the  items  in  Guide's  normal  menu  either 
suppressed  or  replaced.  (Guide  options  are,  incidentally,  mostly  controlled  by  UNIX  environment 
variables  and  switches;  some  could  profitably  be  controlled  by  mark-up  within  source  files,  but 
currently  this  is  not  supported.) 

Size  of  file 

The  design  of  source  file  formats  is  somewhat  influenced  by  the  size  of  a  typical  file:  is  it  a  single 
'page'  or  could  a  whole  encyclopedia  be  stored  in  a  single  file.  In  practice  Guide  authors  vary 
considerably:  some  have  tiny  files  and  some  have  files  containing  megabytes  of  text.  In  the  latter 
case  there  is  a  significant  pause  while  the  file  is  loaded  but  thereafter  speed  is  superb. 

Typically  the  initial  screen  consists  of  a  summaiy,  which  consists  of  a  skeleton  document  with 
buttons  representing  the  components  of  the  document.  Initially  no  buttons  are  expanded. 
However  Guide's  source  file  format,  where  normally  the  replacement  of  a  button  immediately 
follows  the  button-name,  means  that  the  whole  source  file  needs  to  be  loaded  in  order  to  paint  the 
initial  screen.  Indeed  because  of  this  Guide  always  loads  complete  source  files,  making  no  effort 
to  restrict  itself  to  the  parts  that  are  actually  needed.  In  the  environment  where  Guide  runs. 


-56- 


workstations  with  a  lot  of  real  storage,  supplemented  by  virtual  storage,  this  has  caused  no 
problems.  However  OWL's  Guide,  which  can  nm  in  much  more  constrained  environments  than 
UNIX  Guide,  has  adopted  a  file  format  that  does  allow  parts  of  the  files  to  be  loaded.  OWL  uses  a 
structured  tile  format  where  associated  tables  designate  where  constructions  begin  and  end. 

Conversion  between  hypertext  systems 

Although  UNIX  Guide  and  OWL  Guide  have  identical  parentage  and  similar  hypertext 
mechanisms,  it  would  be  a  major  job  to  convert  source  files  between  the  two.  This  is  not  because 
file  formats  are  different,  but  because  there  are  significant  differences  in  the  way  linking  is  done 
(e.g.  UNIX  Guide's  late  binding  approach  is  not  found  in  OWL  Guide). 

A  conversion  has  never  been  attempted  but,  if  it  were,  it  would  be  a  similar  exercise  to  converting 
between  two  somewhat  similar  programming  languages:  you  may  get  an  automatic  tool  to  convert 
90%  of  a  program,  but  the  rest  would  need  doing  by  hand.  Even  within  the  90%  that  was 
automatically  converted,  there  would  be  odd  differences  in  program  behaviour. 

A  complete  conversion  between  two  radically  different  hypertext  systems  would  clearly  be  harder 
still.  It  is  not  the  source  file  format  that  is  the  problem,  but  fundamental  differences  in  approach. 
This  is  why  we  believe  that  this  is  the  area  where  standard  file  formats  have  least  to  offer.  There 
is,  of  course,  the  possibility  of  a  deeper  standard  which  specifies  how  hypertext  systems  actually 
work.  In  practice  there  is,  however,  no  more  chance  of  getting  creators  of  hypertext  systems  to 
agree  than  getting  designers  of.  say,  programming  languages  to  agree. 

ConcSusions 

The  tone  of  this  paper  has  been  at  least  lukewarm  about  standards. 

Nevertheless  UNIX  Guide  can  hardly  claim  to  be  a  major  force  that  will  materially  affect  that 
standardisation  movement,  and  hence  standards  may  come.  If  they  do  come  we  hope  they: 

•  are  geared  to  exchange  with  other  software  (word-processors,  picture  drawing 
programs,  databases,  etc)  rather  than  specifically  with  other  hypertext  systems. 

•  are  geared  to  taking  advantage  of  existing  tools. 

•  are  based  on  ASCII  files  that  can  be  read,  edited,  etc,  by  humans,  and  can  be  sensibly 
transmitted  down  pipes  and  similar  mechanisms. 

•  can  treat  straight  text  files  as  a  subset  of  hypertext  files,  rather  than  as  special  cases. 

•  are  not  based  on  a  specific  linking  mechanism.  If  late  binding  is  used,  the  linking 
mechanism  is  not  very  relevant  to  source  formats. 

allow  flexibility  in  the  region  of  replacement  so  Guide  enquiries  and  their  equivalents 
in  other  systems  can  be  supported. 

•  cater  for  higher-level  user-defined  abstractions  and  house-styles. 

•  allow  other  software  to  share  hypertext  files  without  the  need  for  conversion 
problems. 

References 

Brown,  P.J.  (1989).  'A  hypertext  system  for  UNIX',  Computing  Systems,  2,  7,  pp.  37-53. 

Brown,  P.J.  (1990).  'Hypertext:  dreams  and  reality',  in  Lennox,  G.  (Ed.) 
Hypertext/Hypermedia  and  object-oriented  databases,  Kogan  Page,  London. 

Conklin,  J.  (1987).  'Hypertext:  introduction  and  survey',  IEEE  Computer,  20,  9,  pp.  17-41. 


-57- 


ISO  (1986).  ISO  8879  —  Text  and  Office  Systems  —  Standard  Generalized  Markup 
Language  (SGML). 

ISO  (1988).  ISO  8613  —  Text  and  Office  Systems  —  Office  Document  Architecture  (ODA) 
and  Interchange  Format. 

Meehan,  D.P.  (1987).  Locator:  a  system  for  service-desk  8801  fault  diagnosis,  M.Sc.  thesis, 
Kingston  Polytechnic,  Kingston,  U.K. 

Meyrowitz,  N.  (1987).  'The  missing  link:  why  we're  all  doing  hypertext  wrong',  position 
paper.  Hypertext  87,  University  of  North  Carolina. 


-58- 


Standards:  What  Can  Hypertext  Learn  From  Paper  Documents? 

Fred  Cole 
Heather  Brown 

Computing  Laboratory 
University  of  Kent 
Canterbury 
CT2 7NF 
England 


1.  Introduction 

Hypertext  literature  tends  understandably  to  concentrate  on  what  is  new  and  to  ignore,  or  take  for  granted, 
the  properties  of  hypertext  that  are  also  present  in  paper  documents.  The  purpose  of  this  paper  is  to 
consider  how  the  expertise  that  exists  in  standards  and  models  for  paper  documents  can  be  used  to  save 
effort  when  designing  a  standard  for  hypertext,  and  how  to  make  hypertext  and  paper  document  standards 
compatible.  Section  2  discusses  some  relevant  similarities  between  paper  and  hypertext  documents. 
Section  3  introduces  relevent  aspects  of  the  Office  Document  Architecture  (ODA)  [1]  and  suggests  ways  to 
build  on  ODA  to  create  a  standard  that  combines  the  strengths  of  the  two  areas. 

2.  Similarities  between  paper  and  hypertext  documents 

2.1.  The  need  to  separate  the  logical  structure  and  its  presentation 

Although  hypertext  systems  vary  widely  in  appearance  and  functionality  they  generally  have  similar 
underlying  document  structures  —  directed  graphs  in  which  the  nodes  hold  the  content  and  the  arcs 
represent  links  of  various  types.  The  way  in  which  the  nodes  and  links  are  presented  on  the  screen,  and 
what  happens  when  a  link  of  a  particular  type  is  activated,  are  peculiar  to  (and  usually  hardwired  into)  the 
hypertext  system. 

If  a  standard  for  hypertext  is  to  be  effective,  it  must  allow  a  hypertext  to  be  created  on  one  system  and 
presented  on  another.  In  particular  it  must  allow  for  the  possibility  that  the  receiving  system  does  not  have 
the  capability  to  perform  the  presentation  as  intended  on  the  original  system.  To  do  this  it  should  represent 
separately: 

(i)  the  components  in  the  underlying  logical  structure; 

(ii)  the  specification  of  presentation  facilities  on  each  participating  system  (including  dynamic  properties 
such  as  the  actions  allowed  when  hotspots  are  selected); 

(iii)  a  mapping  from  (i)  to  the  relevant  set  in  (ii)  for  each  participating  system. 

This  separation  of  the  logical  structure  from  the  method  of  presentation  is  not  just  an  inconvenience  needed 
for  portability;  it  is  a  positive  feature  that  can  be  used  to  give  hypertext  some  of  the  advantages  that  were 
given  to  paper  documents  by  generic  markup  and  structured  editors. 

Markup  of  documents  intended  for  paper  used  to  be,  and  in  many  cases  still  is,  presentation  oriented. 
Formatting  commands  are  inserted  into  the  document  to  request  explicit  presentation  features  such  as 
moving  the  current  print  position  or  changing  to  a  given  font  style  or  size.  Generic  markup,  on  the  other 
hand,  is  concerned  with  the  logical  structure  of  the  document  —  it  marks  portions  of  the  content  as 
belonging  to  particular  named  classes.  The  actual  layout  and  presentation  are  bound  to  the  name  later 
(either  by  the  publisher,  using  traditional  markup,  or  by  a  computer  formatting  system).  Generic  markup  is 
essentially  for  non-interactive  systems.  The  interactive  equivalent  is  the  structured  document  editor,  which 
works  in  a  similar  manner  by  assigning  a  named  class  to  each  document  constituent  and  providing  separate 


-59- 


'style  sheets'  to  specify  the  presentation  of  constituents  belonging  to  the  class.  The  appearance  of  all 
constituents  belonging  to  the  class  can  be  changed  by  altering  the  style  sheet. 

In  both  cases  the  effect  is  to  separate  low-level  presentation  details  from  the  logical  document  structure  and 
content  (as  in  (i)  and  (ii)  above)  and  to  allow  or  provide  a  means  of  binding  the  two  together  at  a  later  stage. 
This  late  binding  corresponds  to  the  mappings  in  (iii)  above. 

In  the  logical  structure  of  the  document  the  named  classes  should  correspond  to  the  function  of  the  content 
rather  than  the  method  of  its  presentation  ('title'  or  'reference'  rather  than  'change  to  bold  type',  for 
example).  Generic  markup  and  structured  editing  are  acknowledged  (see  [2]  for  example)  to  have  many 
advantages  including: 

making  it  easier  to  present  the  document  in  another  style  (that  of  a  different  publisher,  for  example) 
without  extensive  manual  changes  to  the  text  —  this  is  the  paper  equivalent  of  presenting  a  hypertext 
on  a  different  system. 

helping  to  maintain  a  consistent  style  throughout  the  document,  and  making  it  easier  to  enforce  a 
house  style. 

•       improving  typographic  quality  by  discouraging  authors  from  dabbling  in  low  level  details  and 
leaving  the  design  of  styles  to  experts 

forcing  the  author  to  consider  the  structure  of  the  document.  This  usually  results  in  a  better  structure 
—  and  could  be  particularly  important  for  hypertexts. 

Where  layout  and  presentation  facilities  are  complex,  this  separation  of  the  logical  and  presentation  aspects 
of  the  document  often  results  in  considerable  factorisation  of  information  and  consequently  in  reduced  costs 
for  transmitting  a  document. 

2.2.  Links 

Paper  documents  have  links  —  intra-document  links  to  components  of  the  logical  structure  ("see  section 
3.5")  or  to  part  of  a  particular  representation  ("see  page  27"),  and  inter-document  links  (bibliographic 
references).  Each  link  (in  a  well-written  document)  is  accompanied  by  some  indication  of  what  the  reader 
can  expect  to  find  at  the  other  end,  or  at  least  the  reason  the  author  has  for  directing  the  reader  there. 
Hypertext  differs  only  in  that,  instead  of  indicating  the  position  ("page  27")  of  the  remote  object,  it  offers 
some  means  of  automatically  accessing  and  presenting  the  remote  object. 

If  a  system  is  to  be  able  to  edit  or  reformat  a  paper  document  and  still  retain  the  integrity  of  its  links,  then 
each  link  must  be  represented  at  the  logical  level  in  much  the  same  way  as  it  would  be  in  a  hypertext.  It 
might,  for  example,  have  a  type,  a  reference  to  the  identifier  of  a  remote  object  and,  associated  with  the 
type,  a  specification  for  how  it  is  to  be  presented. 

2.3.  Hierarchical  structures 

In  paper  documents  the  logical  components  referred  to  above  are  typically  arranged  in  a  hierarchical  tree- 
like structure.  A  book,  for  example,  might  contain  chapters  which  contain  sections  which  contain 
paragraphs.  This  structure  is  primarily  a  tree  but  it  may  be  supplemented  by  link  components  that  cut 
across  the  normal  tree  links  and  turn  the  structure  into  a  directed  graph. 

Although  hypertext  systems  emphasise  the  links  more  than  paper  documents,  their  underlying  models  are 
similar.  Indeed,  several  hypertext  systems  recommend  or  enforce  a  general  hierarchical  model  to  minimise 
the  well-known  problem  of  readers  becoming  lost  [3,4]. 

To  represent  a  hypertext  within  the  hierarchical  model  for  paper  documents,  we  could  start  by  assuming 
that  the  logical  structure  components  referred  to  above  might  simply  be  the  links  and  nodes  of  the 
document.  In  this  case  each  node  would  be  very  simple,  consisting  of  a  single  piece  of  basic  information 
together  with  hierarchical  and  non-hierarchical  links.  The  hierarchical  links  would  form  the  basic  tree 
structure,  and  the  non-hierajchical  links  would  be  the  link  components. 

Most  hypertexts  could  not  be  represented  by  such  a  simple  structure,  however,  and  there  is  a  need  for 
internal  structure  for  a  node.  A  finer  granularity  is  needed,  in  which  each  node  is  structured  hierarchically 
into  a  number  of  subordinate  components  (including  links)  representing  paragraphs,  parts  of  paragraphs, 
diagrams,  buttons,  hotspots  and  such  like.  The  hypertext  node  thus  becomes  a  subtree  and  this  makes  it 


-60- 


possible  to  represent  the  node  in  a  way  very  similar  to  that  in  which  we  represent  a  page  of  a  paper 
document  (although  in  some  cases  the  'page'  might  be  so  large  that  it  needs  to  be  scrolled).  Rules  for 
laying  out  and  presenting  the  components  of  the  node  could  then  be  specified  in  the  way  they  are  specified 
for  a  page  of  a  paper  document. 

2.4.  Style  and  the  problem  of  getting  lost 

As  shown  above  a  single  node  of  a  hypertext  is  similar  in  many  respects  to  a  page  or  logical  section  of  a 
paper  document,  and  it  has  long  been  recognised  that  the  meaning  of  a  page  of  information  —  and  the  ease 
with  which  this  meaning  is  understood  —  is  very  dependent  on  the  skill  with  which  the  page  is  laid  out. 
Those  unskilled  in  the  art  of  typography  are  well  advised  to  leave  the  design  of  the  document  styles  to 
experts.  For  a  hypertext,  style  would  include  the  positioning  and  presentation  of  different  types  of  button  or 
hotspot  as  well  as  text  and  diagrams.  The  structures  described  above  would  allow  all  the  sophistication 
used  for  laying  out  a  page  of  a  paper  document  to  be  applied  equally  to  laying  out  a  node  of  a  hypertext. 

Early  applications  of  the  standard  will  probably  be  in  automatic  translators  between  existing  hypertexts  and 
the  standard,  in  which  case  the  separate  logical  structure  and  the  late  binding  will  initially  be  hidden  from 
end  users.  It  would  be  wise  however  to  ensure  that  the  standard  allows  for  future  improvements  in 
hypertext.  A  reasonable  assumption  is  that  hypertext  systems  could  learn  design  techniques  from  paper 
document  processing  systems,  including  the  principles  inherent  in  generic  markup,  in  order  to  gain  the 
advantages  listed  above  and  especially  to  help  authors  to  improve  the  styles  of  their  hypertexts. 

Well  defined  and  consistent  styles  have  a  bearing  on  the  problem  of  getting  lost  in  hyperspace  [4],  the 
solution  to  which  has  often  been  considered  to  be  a  matter  of  giving  the  user  a  suitable  overall  graphic  view 
(or  map)  of  all  or  part  of  the  document.  There  is  reason  to  believe  tliat  this  may  not  be  the  only  or  even  the 
best  method  [5]  and  that  perhaps  good  authorship  may  make  it  unnecessary  for  the  user  (including  authors?) 
to  be  aware  of  the  underlying  directed  graph.  Well-designed  generic  styles  could  be  a  way  of  helping  users 
with  this  problem. 

2.5.  Compatibility  between  paper  and  hypertext  documents 

It  would  be  foolish  to  ignore  the  need  to  produce  a  paper  version  of  part  of  a  hypertext,  and  it  also  seems 
sensible  to  make  provision  for  readers  to  have  the  advantages  of  hypertext  navigation  when  viewing  a 
document  on  the  screen  —  even  if  the  document  is  eventually  intended  to  be  read  from  paper.  These  aims 
could  best  be  achieved  by  having  a  common  underlying  representation  for  the  structures  of  both  types  of 
document,  together  with  well  designed  ways  of  mapping  those  structures  onto  different  forms  of 
representation.  It  is  not  suggested,  of  course,  that  a  document  designed  for  paper  would  necessarily  make  a 
good  hypertext  or  vice  versa,  only  that  a  usable  representation  should  be  readily  available  by  applying 
different  presentation  styles. 

3.  A  hypertext  standard  based  on  ODA? 

ODA  is  a  standard  for  the  storage  and  interchange  of  complex  multimedia  documents.  The  ODA  document 
model  is  hierarchical  and  object-oriented.  It  caters  for  both  source  (processable)  documents  and  output 
(formatted)  documents.  Currently  ODA  documents  can  contain  three  types  of  content  (character,  raster 
graphics  and  geometric  graphics)  but  other  types  of  content  will  soon  be  added. 

Several  major  extensions  to  ODA  are  already  under  consideration  in  the  relevant  committees  and  working 
groups.  These  include  tabular  layout,  video  material,  the  inclusion  of  data  in  documents  —  and  hypertext. 
The  SGML  [6]  community  is  also  starting  to  consider  hypertext  extensions.  It  would  be  tragic  if  three 
separate  hypertext  standards  emerged:  one  based  on  ODA,  one  based  on  SGML,  and  a  completely  separate 
one  from  the  hypertext  community.  After  several  years  of  rivalry  and  backbiting  the  ODA  and  SGML 
committees  are  showing  encouraging  signs  of  working  together,  so  there  is  some  hope  that  these  two  may 
merge. 

The  details  and  suggestions  given  below  are  based  on  ODA,  largely  because  ODA  currently  includes 
graphics  and  images  and  defines  a  layout  process  to  map  from  the  logical  structure  of  tlie  document  to  a 
formatted  form.  However,  the  genera!  principles  could  apply  to  SGML  when  used  with  DSSSL  [7]  which 
defines  a  presentation  model  for  SGML  documents. 


-61- 


The  following  subsections  describe  the  features  currently  in  ODA  that  make  it  useful  as  a  basis  for  a 
hypertext  standard  and  then  the  features  that  we  believe  must  be  added.  These  new  features  are  needed  to 
improve  the  ability  of  ODA  to  represent  all  the  features  of  high  quality  paper  documents,  but  are  also 
intended  to  prepare  the  way  for  the  hypertext  extensions  to  ODA. 

3.1.  What  ODA  can  already  offer  to  hypertext 

The  following  sections  give  a  brief  description  of  ODA  as  it  applies  to  paper  documents. 

3.1.1.  ODA  Document  Architecture 

ODA  provides  a  tree-like  model  of  a  document.  The  structure  of  the  document  is  given  by  the  shape  of  the 
tree,  while  the  content,  is  stored  entirely  in  the  leaf  objects.  Aitributes  provide  information  about  the 
objects.  A  few  of  the  most  important  attributes  are  introduced  in  the  examples  and  discussion  below.  Only 
one  needs  to  be  mentioned  at  this  stage.  This  is  the  content  architecture  attribute  that  defines  the  type  of 
content  for  each  leaf  object  and  thus  allows  different  types  of  content  to  co-exist  within  the  document. 

An  ODA  document  is  described  by  two  structures.  The  logical  structure  divides  and  subdivides  the  content 
of  the  document  into  logical  objects  that  mean  something  to  the  human  author  or  reader.  A  logical  object 
may  be  a  general  item  like  a  section,  title,  paragraph  or  reference.  Alternatively  it  may  be  a  specialised 
item  like  a  telephone  number  or  price,  or  a  collection  of  related  information  like  a  list  of  companies  selling 
a  particular  product.  Only  the  lowest  level  objects,  such  as  titles  or  prices,  have  content. 

The  layout  structure  is  concerned  with  a  visible  representation  of  the  content.  It  divides  and  subdivides  the 
content  into  page  sets,  pages,  and  rectangular  areas  within  pages.  Rectangulai'  areas  with  nested  areas 
defined  within  them  are  known  as  frames.  The  lowest  level  aieas  are  known  as  blocks  and,  by  definition,  are 
the  only  areas  to  have  content  associated  with  them.  A  frame  might  be  used  to  represent  a  column  of  text, 
for  example,  with  nested  blocks  for  the  content  of  individual  paragraphs. 

Each  document  has  its  own  specific  logical  and  specific  layout  structure,  but  their  creation  is  guided  and 
controlled  by  generic  document  structures  for  that  particular  class  or  'style'  of  document.  These  are  sets  of 
object  type  definitions  (one  set  for  logical  objects  and  one  for  layout  objects)  that  specify  the  types  and 
combinations  of  objects  allowed.  In  ODA  terminology  tlie  definitions  constitute  the  generic  logical  and 
generic  layout  structures  for  a  document  class. 

3.1.2.  Examples  of  ODA  Structures 

This  section  illustrates  the  structures  introduced  above  by  presenting  snippets  of  the  generic  structures  that 
might  be  used  for  a  journal  containing  technical  papers.  It  also  introduces  a  few  important  attributes. 

The  generic  definition  for  each  non-leaf  object  has  an  atixibute  called  generator  for  subordinates  lliat 
describes  how  the  object  may  be  made  up  from  subordinate  objects.  These  indicate  that  subordinate  objects 
may  be  optional  (OPT),  required  (REQ),  repeated  (REP),  or  optional  and  repeated  (OPT  REP),  and  that  a 
group  of  objects  may  occur  in  a  given  sequence  order  (SEQ),  in  any  order  (AGG),  or  as  a  choice  where 
only  one  of  the  group  occurs  (CHO).  The  information  given  in  these  attributes  provides  a  simple  grammar 
for  the  primary  structure  of  the  document  class. 

Figure  1  shows  the  generic  logical  structure  for  a  single  technical  paper  in  the  journal.  It  indicates  that  the 
paper  consists  of  a  compulsory  title,  followed  by  a  compulsory  author's  name,  followed  by  an  optional 
abstract,  followed  by  one  or  more  sections.  If  the  abstract  is  present  it  consists  of  a  single  paragraph.  Each 
section  begins  with  a  subtitle.  The  'REP  CHO'  conslruct  indicates  thiat  the  subtitle  is  followed  by  a  series 
of  paragraphs  or  lists  occurring  in  any  order.  Lists  consist  of  one  or  more  list  items.  (In  practice,  a  more 
complex  structure  catering  for  items  like  footnotes  and  diagrams  would  be  needed.) 

The  conesponding  generic  layout  structure  might  define  one  page  style  for  the  first  page  of  the  paper,  and  a 
different  style  for  all  subsequent  pages.  Figure  2  shows  the  top  level  of  such  a  structure.  The  Title  page' 
contains  a  'Header  frame'  representing  an  area  set  aside  for  the  title,  autlsor's  name  and  abstract,  and  a 
'Body  frame'  for  the  start  of  the  first  section.  The  'Continuation  pages'  coniain  'Continuation  body  frames' 
to  hold  the  rest  of  the  sections.  (Again,  in  practice,  further  frames  would  be  needed  for  items  like  running 
titles.)  Blocks  are  not  included  in  the  generic  layout  structure  but  are  assigned  to  pages  and  frames  during 
the  layout  process  as  outlined  below. 


-62- 


Paper 


SEQ 


TiUe 


Paper  page  set 


OPT 


REP 


Author 


Abstract 


Section 


Head 


Head 


SEQ 


Paragraph 


Head 


REP 

Subtitle 

CHO 

Body 

j  Paragraph 

List 

Body 

REP 

List  item 

Body 


Figure  1 :  Generic  logical  structure 


Paper 
page  set 


SEQ 


OPT  REP 


Title 
page 


AGG 


Header 
frame 

Body 
frame 

Contir 
pa 

uation 

ge 

Continuation 
body  frame 

Body 


Head  Body 

Figure  2:  Generic  layout  structure 

ODA's  layout  process  decides  exactly  where  each  item  of  the  document  is  to  be  placed.  It  uses  the  specific 
logical  structure,  the  generic  structures,  and  the  content  architectures  to  create  the  specific  layout  structure. 
It  works  at  two  levels 

Content  layout  takes  portions  of  content  and  lays  them  out  into  blocks.  This  stage  is  dependent  on 
the  content  architectures  involved  and  on  sets  of  attributes  known  as  presentation  styles. 

•       Document  layout  places  blocks  in  frames  or  pages.  This  stage  is  dependent  on  sets  of  attributes 
known  as  layout  styles. 

The  content  layout  process  thus  deals  with  character  sets  and  tlie  fine  positioning  of  items  within  blocks, 
while  the  higher  level  document  layout  process  decides  how  to  place  the  blocks  within  pages  and  frames. 

The  document  layout  process  is  guided  by  three  attributes  whose  values  are  shown  in  italics  in  Figures  1 
and  2.  Layout  object  class  is  normally  used  to  indicate  that  a  major  logical  division  of  the  document  should 
be  directed  into  a  particular  page  or  page  set.  In  the  example  the  logical  'Paper'  has  its  layout  object  class 


-63- 


defined  as  'Paper  page  set'.  This  dictates  that  each  paper  must  be  laid  out  in  a  single  instance  of  the  page 
set  shown  in  Figure  2. 

Within  a  layout  object  class,  the  attributes  layout  category  and  permitted  categories  can  be  used  to  direct 
logical  objects  into  different  frames.  If  a  leaf  logical  object  is  given  a  layout  category  name,  it  can  only  be 
laid  out  in  a  frame  that  has  the  same  name  as  one  of  its  permitted  categories.  In  the  example  the  only 
category  names  used  are  'Head'  and  'Body'.  When  the  layout  process  tries  to  place  the  blocks 
corresponding  to  the  title,  author's  name,  and  abstract  (if  present),  it  will  look  for  a  frame  with  'Head'  as  a 
permitted  category,  and  will  therefore  create  a  'Title  page'  and  place  them  in  the  'Header  frame'.  But  when 
it  reaches  rhe  blocks  corresponding  to  the  contents  of  the  sections  it  looks  for  frames  with  'Body'  as  a 
permitted  categor)',  so  it  uses  the  'Body  frame'  until  that  is  full  and  then  creates  'Continuation  pages'  as 
necessary  in  order  to  use  the  'Continuation  body  frames'. 

When  the  specific  layout  structure  has  been  created,  it  associates  the  document  content  with  pages,  frames 
and  blocks.  The  two  specific  structures  are  related  and  come  together  at  the  level  of  the  content.  Figure  3 
shows  a  fragment  of  the  specific  structures  for  the  beginning  of  a  paper.  It  assumes  the  paper  has  no 
abstract  and  that  the  first  section  begins  with  three  paragraphs,  only  one  of  which  fits  onto  the  title  page. 
Figure  3  shows  a  neat  one-to-one  correspondence  between  logical  objects  and  layout  objects.  This  often 
occurs,  but  not  always.  Lx)gical  content  portions  may,  for  example,  be  split  between  blocks  (when 
paragraphs  are  split  over  pages)  or  concatenated  into  paragraphs  occupying  a  single  block. 


LOGICAL 
STRUCTURE 


Paper 


Title 


Author 


Subtitle 


Content 

Content 

Block 

Block 

Content 


Section 


I  Paragraph 


Paragraph 


Content 


Paragraph 


Content 


Content 


LAYOUT 
STRUCTURE 


Block 


Figure  3:  Specific  logical  and  layout  structures 


3.1.3.  Providing  Different  Views  of  an  ODA  Document 

The  previous  section  gave  only  a  brief  sketch  of  the  ODA  layout  process,  but  it  should  be  sufficient  to  show 
that  the  appearance  of  a  specific  logical  document  can  be  altered  by  judicious  changes  to  its  generic  layout 
structure.  As  a  simple  example,  deleting  the  'Body  frame'  from  the  'Title  page'  in  Figure  2  would  cause 
each  paper  to  be  laid  out  with  only  the  title,  author's  name  and  abstract  on  the  first  page.  There  would  be 


-64- 


no  frame  on  the  first  page  with  'Body'  as  a  permitted  category,  so  the  first  section  would  have  to  start  on  a 
new  page  in  a  'Continuation  body  frame'. 

More  radical  changes  to  the  layout  can  be  achieved  by  altering  the  attributes  that  make  up  the  layout  and 
presentation  styles.  The  attributes  in  these  styles  apply  to  logical  objects,  but  the  objects  contain  only  the 
identifier  of  the  appropriate  style.  The  styles  themselves  are  held  separately.  This  provides  a  more  concise 
document  representation  and  allows  the  styles  to  be  changed  without  changing  the  logical  structures. 

The  layout  styles  include  the  layout  object  class  and  layout  category  attributes  (described  in  the  previous 
section)  and  other  attributes  governing  the  selection  of  frames  and  the  positioning  of  blocks  within  a  frame. 
The  same  layout  object  attribute,  for  example,  constrains  the  block  containing  the  logical  object  to  share  the 
same  frame  as  the  block  containing  another  specified  object,  while  new  layout  object  consu-ains  the  block 
containing  the  object  to  start  a  new  frame.  Offset  and  separation  control  the  minimum  spacing  between 
adjacent  blocks,  and  the  relative  position  of  blocks  is  dictated  by  Jill  order  which  allows  normal  top-to- 
bottom  positioning  or  traditional  footnote  positioning. 

The  presentation  styles  guide  the  lower-level  content  layout  process  and  thus  affect  the  appearance  of 
content  within  individual  blocks.  They  contain  different  attributes  for  different  content  architectures.  For 
character  content,  for  example,  they  include  attributes  affecting  the  indentation  of  the  first  line,  the  distance 
between  lines,  and  the  initial  font  size. 

Changing  the  generic  layout  structure  and  the  styles  can  lead  to  significantly  different  views  of  the  same 
logical  document.  Page  and  margin  sizes  can  vary,  single  or  double  column  layout  can  be  used,  and 
paragraph  spacing  and  font  size  can  change.  In  particular,  it  is  possible  to  cater  for  different  'house  styles' 
by  this  means  and  to  provide  different  styles  for  interactive  editing  and  the  final  printed  version.  ODA  is 
not  as  flexible  as  it  should  be  in  this  respect  because  it  has  insufficient  separation  between  the  logical  and 
layout  structures.  We  are  attempting  to  get  this  changed  (see  below). 

3.2.  What  ODA  still  lacks 

The  structures  and  styles  introduced  above  form  a  good  basis  for  a  flexible  standard  for  paper  documents 
and  provide  at  least  some  of  the  requirements  for  a  hypertext  standard.  We  have  identified  a  number  of 
deficiencies  in  the  ODA  standard  and  have  investigated  changes  to  the  standard  that  would  overcome  them. 
The  changes  are  needed  in  order  to  improve  the  representation  of  paper  documents  but  were  designed  with 
the  aim  of  preparing  the  way  for  an  extension  of  ODA  to  deal  with  hypertext.  ISO/IEC  JTCl/SC  18/SWG 
(the  special  working  group  responsible  for  changes  to  the  standard)  has  already  declared  its  intention  to 
develop  such  an  extension.  We  have  explained  the  deficiencies  and  our  suggestions  for  improvement  in  a 
paper  [8]  that  is  to  be  considered  by  the  special  working  group  in  January  1990.  Brief  outlines  of  the 
deficiencies  for  which  we  have  offered  cures  are  given  below. 

3.2.1.  Separating  logical  structure  from  presentation 

One  of  the  strengths  of  ODA  is  its  attempted  separation  of  the  logical  and  layout  structures,  but  this  does 
not  go  far  enough,  so  we  have  made  suggestions  to  make  it  complete.  If  it  is  required  to  change  the  style  of 
a  document  (to  the  house  style  of  a  different  company  or  different  publisher,  for  example)  it  should  not  be 
necessary  to  edit  the  logical  structure,  only  to  apply  a  different  set  of  layout  and  presentation  styles  to  create 
a  different  "view"  of  the  same  logical  document.  This  facility  to  change  the  view  without  changing  the 
document  is  part  of  the  answer  to  the  problem  of  exchanging  hypertexts  between  different  systems  that 
have  different  presentadon  capabilities  or  different  presentation  conventions. 

3.2.2.  Comprehensive  attribute  inheritance 

The  ODA  mechanism  for  inheriting  layout  and  presentation  attributes,  in  spite  of  its  complex  algorithm  for 
finding  default  values,  is  insufficient.  If  an  attribute  value  is  not  specified  for  the  object  or  its  class  then  the 
value  can  only  be  inherited  according  to  the  object's  position  in  the  tree  and  not  according  to  its  class 
(chapter,  list  etc.).  Our  suggestion  for  supplying  this  facility  is  Uie  addition  of  'style  tables'  as  described  in 
[8].  The  use  of  style  tables  enables  the  style  inherited  by  an  object  (and  therefore  the  way  it  is  formatted)  to 
depend  both  on  its  class  and  on  its  position  in  the  document.  This  mechanism  is  valuable  for  hypertext 
representation,  making  it  possible  to  distinguish  objects  of  the  same  type  that  are  in  different  states  (open 


-65- 


and  closed  buttons  for  example)  and  can  be  extended  so  that  it  can  specify  changes  of  state  (such  as  those 
that  take  place  when  a  hotspot  is  selected)  by  changing  the  style  table. 

3.2.3.  Links 

In  both  paper  and  hypertext  views  a  document  designer  must  be  able  to  specify  the  purpose  of  each  link, 
and  to  specify  how  the  layout  process  can  express  that  purpose.  In  this  respect  the  requirements  for  hnks 
are  very  similar  to  those  for  logical  objects,  so  it  seems  reasonable  to  deal  with  them  in  the  same  way  —  by 
having  classes  for  links.  The  class  of  the  link  should  determine  how  and  where  in  the  document  the  link 
can  be  used,  and  it  must  be  possible  to  specify  the  representation  of  the  link  in  a  way  that  depends  on  both 
the  class  of  the  link  and  also  its  position  in  the  document. 

We  discovered  that  a  small  number  of  additions  to  the  definition  of  ODA  logical  objects  allows  a  document 
designer  to  use  those  logical  objects  as  links,  with  all  the  functionality  described  above.  These  additions  do 
not  in  any  way  change  existing  definitions  or  change  the  validity  of  existing  documents. 

3.2.4.  Selective  and  multiple  presentation 

ODA  does  not  have  a  mechanism  for  specifying  that  a  logical  object  should  be  ignored  in  the  layout 
process,  nor  that  it  should  be  laid  out  more  than  once.  A  facility  to  ignore  objects  could,  for  example,  allow 
a  document  to  contain  a  reviewer's  annotations  without  those  annotations  appearing  in  a  printout,  or  could 
allow  different  versions  of  the  document  to  be  produced  for  different  situations.  To  achieve  this  we  have 
suggested  a  simple  variation  on  the  style  table  mechanism  described  above.  This  facility  is  obviously 
needed  for  hypertext  because  most  of  a  hypertext  is  not  presented  at  all  until  selected  by  the  user. 

3.3.  Extensions  and  Interactive  Documents 

This  section  shows  how  the  proposed  extensions  can  be  applied  to  screen  based  documents  and  hypertext  in 
general  and  then  looks  in  more  detail  at  how  they  can  be  applied  to  two  particular  hypertext  systems. 

ODA  allows  a  measure  of  flexibility  in  the  layout  and  presentation  of  documents,  but  different  views  are 
not  a  substitute  for  proper  interactive  facilities.  The  basic  problem  is  that  the  ODA  layout  process  is 
sequential  and  page  based  —  and  several  attributes  reflect  Uiis.  Any  form  of  online  editing  requires 
extensions  to  the  layout  process  to  make  it  incremental  and  to  allow  the  user  to  scroU  around  the  document, 
but  some  more  ambitious  features  desirable  for  screen-based  documents  are 

(i)  An  outline  facility  —  to  display  selected  (usually  high  level)  items,  such  as  chapter  and  section 
headings,  and  ignore  other  items. 

(ii)  Pop-up  displays  —  to  allow  the  temporary  display  of  additional  information  on  demand.  These  can 
be  used  for  the  equivalent  of  footnotes,  marginal  notes,  and  glossary  entries  in  paper  documents. 

(iii)  Folding  —  to  allow  sections  of  a  document  to  be  hidden  behind  a  'button'  on  the  screen  and  revealed 
on  request.  Folding  should  be  allowed  to  any  level,  so  hidden  sections  can  contain  further  buttons. 

(iv)  A  linkage  facility  —  to  enable  users  to  follow  links  or  cross-references  automatically. 
Item  (i)  is  dealt  with  by  style  tables  that  select  objects  by  class  and  required  level. 

Item  (ii)  is  dealt  with  by  changing  to  another  style  table  to  produce  a  pop  up  display  and  then  changing 
back  again  when  the  display  is  no  longer  required. 

Item  (iii)  is  an  extension  of  item  (ii).  The  layout  process  needs  be  able  to  display  either  the  button  or  the 
item(s)  folded  behind  the  button.  One  way  to  do  this  is  to  have  both  the  button  text  and  the  folded 
components  as  subordinates  of  the  button  object.  The  button  is  closed  when  a  style  table  is  applied  that 
displays  just  the  button  text,  and  it  is  opened  by  applying  anoflier  style  table  that  displays  the  folded  items 
(and  possibly  the  button  text  as  well). 

Item  (iv)  could  be  done  in  several  ways  depending  on  the  type  of  link.  Three  possibilities  are 
Move  the  current  point  of  display  to  the  target  object. 
Display  the  target  object  (or  subtree)  as  a  temporary  pop-up  item. 
Include  the  target  object  (or  subtree)  at  this  point  in  the  document. 


-66- 


These  can  be  achieved  with  a  combination  of  style  tables  and  links.  The  style  table  specifies  whether  on 
not  to  display  the  linked  object.  When  the  style  table  is  changed  the  linked  object  can  be  displayed  as  a 
new  layout  object  (like  a  card),  as  a  pop  up  item,  or  inserted  inline  with  the  surrounding  content. 

3  J.l.  Modelling  Guide  Buttons  in  ODA 

Guide  [9, 10]  is  a  hypertext  system  that  supports  a  hierarchical  model  of  a  document  and  also  allows  cross- 
linking  of  information.  A  typical  Guide  document  presents  the  reader  with  a  summary  consisdng  mainly  of 
buttons.  These  can  then  be  selected  to  reveal  greater  levels  of  detail  as  required.  Buttons  may  be  nested 
many  levels  deep.  The  reader  selects  only  the  buttons  he  is  interested  in,  and  if  he  finds  he  is  not  interested 
in  the  information  revealed  he  can  'undo'  the  selection  and  fold  the  information  back  behind  the  button 
again.  Guide  is  also  a  WYSIWYG  editor.  It  allows  the  reader  to  edit  the  contents  of  the  document  and  to 
add  or  delete  buttons,  thus  becoming  an  author  as  well.  The  emphasis  is  on  allowing  the  reader  to  tailor  the 
document  to  his  own  requirements. 

The  overall  Guide  model  is  similar  to  ODA's  hierarchical  model,  but  with  the  added  concepts  of 

(i)  Folding  logical  items  behind  buttons. 

(ii)  Allowing  more  than  one  button  to  access  the  same  logical  items. 

Guide's  layout  model  is  of  a  single  long  scrollable  frame  holding  all  content  except  temporary  pop-up 
items.  Using  an  ODA  framework  could  enrich  the  Guide  layout  model.  To  show  how  the  Guide  model  fits 
with  ODA,  we  shall  introduce  two  different  types  of  Guide  button  and  explain  how  they  might  be 
represented.  (The  examples  use  the  UNIX  version  of  Guide,  which  is  similar  to  the  version  marketed  by 
OWL  for  the  Apple  Macintosh  [11]  but  differs  in  some  details.) 

The  commonest  type  of  button  is  the  replacement-button.  When  a  replacement-button  is  selected,  the 
button  itself  disappears  and  is  replaced  by  information  that  may  in  turn  contain  further  buttons.  The 
replacement  is  inline,  so  surrounding  text  may  be  reformatted  or  scrolled  out  of  the  way  to  make  room  for 
the  replacement. 

Figure  4  shows  two  different  views  of  a  Guide  version  of  part  of  the  ODA  standard.  In  Figure  4(a)  the 
visible  text  is  made  up  entirely  of  buttons  giving  section  headings.  (By  convention,  Guide  buttons  appear 
in  a  distinctive  font  —  typically  in  bold  —  so  that  readers  can  recognise  them.)  Figure  4(b)  shows  the 
result  of  selecting  the  'Object  Descriptions'  button.  Two  further  buttons  are  shown  within  the  replacement 
The  'More'  button  is  another  replacement-button  for  the  user  to  select  if  he  requires  more  detail.  The 
words  in  itaUcs  are  a  different  type  of  button  known  as  a  glossary-button.  If  the  reader  selects  a  glossary- 
button  an  explanation  of  the  term  appears  temporarily  in  a  separate  window. 

To  represent  Guide  buttons  in  an  ODA  document  we  would  not  set  about  defining  a  special  new  ODA 
object  class  for  each  type  of  button.  Instead,  for  replacement-buttons,  we  would  look  first  at  the  existing 
objects  in  a  document  class,  decide  which  were  appropriate  as  buttons,  and  apply  style  tables  that  would 
make  them  behave  like  buttons.  Sections  might  be  considered  suitable  for  use  as  buttons,  in  which  case  the 
subtitle  might  be  displayed  as  the  button  text,  and  the  whole  object  displayed  when  the  button  is  selected. 
Other  classes  of  object  (list  items  for  example)  might  be  modified  for  use  as  buttons  by  adding  some 
abbreviated  version  as  a  button  text  component. 

There  are  several  variations  on  the  basic  replacement-button.  The  simplest  form  is  the  local-button  where 
the  replacement  applies  only  to  the  button  itself.  This  is  the  default  type  described  above.  Two  other  forms 
are  the  definition-button  and  usage-button.  For  definition-buttons  the  replacement  applies  not  only  to  the 
button  itself  but  also  to  usage-buttons  with  the  same  'name'.  (Guide  provides  a  mechanism  for  attaching 
names  to  the  buttons.)  It  might  be  more  efficient  to  mirror  this  in  ODA  by  providing  usage-buttons  with 
button  text  and  a  link  to  the  appropriate  definition-button  object.  This  then  becomes  a  general  mechanism 
for  attaching  the  subtree  containing  the  replacement  content  to  several  places  in  the  document. 

Glossary-buttons  are  like  footnotes,  annotations,  glossary  entries,  or  other  embellishments  to  the  main 
document.  Unlike  replacement-buttons  their  replacement  is  not  part  of  the  main  document,  instead  it  is 
t>pically  a  short  piece  of  pop-up  text.  We  could  represent  glossar>'-buttons  in  ODA  by  defining  a  new 
'Glossary-button'  generic  object  with  a  generator  for  subordinates  specifying  a  button  text  item  and  a 
'Glossary-text'  item. 


-67- 


2.3.2  Content  portion  descriptions 

2.3.3  Object  descriptions 

2.3.4  Object  class  descriptions 

2.3.5  Styles 

2.3.6  Document  profile 

2.3.7  Document  class  descriptions 


(a)  Summary  containing 
unexpanded  buttons 
only 


2.3.2  Content  portion  descriptions 

2.3.3  Object  descriptions 

Each  object  within  a  structure  is  characterised  by  a  set 
of  attributes  called  an  object  description. 

Each  attribute  has  a  value  and  may  represent  one  of  the 
following  More 

2.3.4  Object  class  descriptions 


(b)  Result  of  selecting 
'Object  Descriptions' 
button 


Figure  4:  Guide  document  showing  (a)  button  and  (b)  expanded  button 

'Glossary-text'  would  normally  be  defined  as  a  simple  leaf  object  with  character  content  (to  represent  the 
explanation  text).  However  glossary-buttons  are  intended  to  provide  the  same  explanation  for  each 
reference  to  a  term  or  item  throughout  the  document,  so  it  is  attractive  to  think  of  a  variation,  similar  to  the 
usage-button,  with  a  link  to  the  appropriate  explanation  text. 

3.3.2.  Modelling  KMS  Frames  in  ODA 

KMS  [3]  supports  a  data  model  based  on  workspaces  known  as  frames.  Frames  may  contain  text,  graphics 
and  image  items,  and  individual  items  within  frames  can  be  linked  to  other  frames.  There  is  no  built-in 
notion  of  hierarchical  organisation  and  no  concept  of  a  linear  ordering  of  information.  Information  is 
divided  into  frame-sized  chunks  and  one  chunk  is  displayed  in  each  window  on  the  screen.  The  reader 
follows  links  to  view  different  frames. 

In  spite  of  this  very  general  model,  strong  conventions  have  evolved  for  the  format  of  frames  and  for 
distinguishing  between  hierarchical  links  and  other  links.  Figure  5  shows  the  overall  layout  of  a 
conventional  KMS  frame.  (To  avoid  confusion  this  section  will  use  'KMS  frame'  and  'ODA  frame'  to 
distinguish  the  different  meanings.) 

The  generic  logical  objects  defined  to  support  a  standard  KMS  database  would  correspond  to  the  KMS 
frame  and  the  items  within  the  KMS  frame.  Figure  6  shows  the  top  levels  of  a  possible  generic  logical 
structure. 

The  generic  layout  structure  for  a  KMS  frame  would  correspond  to  an  ODA  page  with  ODA  frames 
representing  the  areas  shown  within  the  KMS  frame  in  Figure  5.  Layout  object  class  would  be  used  to 
direct  each  KMS  frame  into  a  single  instance  of  this  ODA  page,  and  layout  category  and  permitted 
categories  would  be  used  to  direct  the  different  logical  items  into  the  appropriate  ODA  frames. 

The  'tree'  and  'link'  items  would  be  set  up  like  the  replacement-buttons  described  for  Guide  in  the  previous 
section.  Thus  'tree'  items  would  be  like  definition-buttons  and  would  have  two  subordinates:  the  button 
text  to  be  shown  in  their  parent  KMS  frame  and  another  KMS  frame  (to  be  shown  if  the  button  is  selected). 


-68- 


Frame  title 


Number 


Frame  body 


Tree  items 
Oinks  to  frames 
at  next  level) 


Link  items 
(cross-references) 


Command  items 


Figure  5:  Layout  of  a  typical  KMS  frame 


KMS  frame 


AGG 


AGG 


AGG 


OPT  REP 

OPT  REP 

Frame 

Frame 

Tree 

Command 

Link 

id 

body 

items 

items 

items 

Frame 

Frame 

Button 

KMS 

tide 

number 

text 

frame 

Button 
text 


Figure  6:  Generic  logical  structure  for  a  KMS  frame 

The  'link'  items  would  be  similar  to  usage-buttons.  Tliey  would  have  button  contents  to  be  shown  in  their 
parent  KMS  frame,  and  a  link  to  the  remote  KMS  frame.  The  layout  process  could  be  relatively  simple  as 
it  only  needs  to  display  complete  KMS  frames  and  to  follow  the  primary  and  secondary  links  to  further 
KMS  frames  given  in  the  'tree'  and  'link'  objects. 


4.  Conclusion 

A  great  deal  of  effort  has  gone  into  the  production  of  the  ODA  standard  and  much  practical  experience  has 
been  gained.  A  new  hypertext  standard  should  not  try  to  reinvent  the  wheel.  We  believe  the  best  solution 
is  to  combine  the  existing  expertise  enshrined  in  the  ODA  (and  SGML)  communities  with  the  expertise  in 
the  hypertext  community.  We  must  avoid  having  two  or  three  separate  standards  and  squandering  the 
efforts  of  the  few  experts  available. 


Acknowledgements 

We  would  like  to  thank  British  Telecom  and  the  SERC  for  their  support  of  research  projects  on  document 
structures  and  ODA. 


-69- 


References 

[I]  Information  Processing  -  Text  and  Office  Systems  -  Office  Document  Architecture  (ODA)  and 
Interchange  Format  ISO  8613-1988,  International  Org.  for  Standardisation,  1988. 

[2]     L.Lamport,  LaTeX  user's  guide  and  reference  manual,  Addison-Wesley  Publishing  Company,  1986. 

[3]     R.M.Akscyn,  D.L.McCracken  and  E.A.Yoder,  'KMS:  A  Distributed  Hypermedia  System  for 
Managing  Knowledge  in  Organisations'  CACM,  vol.  31  no.  7,  pages  820  -  835,  1988. 

[4]     J  Conklin,  'Hypertext:introduction  and  survey'  IEEE  Computer  vol  20,  9,  pages  17^1, 1987. 

[5]     P.J.Brown.  X>o  we  need  maps  to  navigate  aiound  hypertext  documents?'  Electronic  Publishing  — 
origination,  dissemination  and  display,  vol  2,  no.  2,  pages  91  -  100, 1989. 

[6]    Information  Processing  -  Text  and  Office  Systems  -  Standard  Generalised  Markup  Language  (SGML) 
ISO  8879-1986,  International  Org.  for  Standardisation,  1986. 

[7]    Information  Processing  -  Text  Composition  -  Document  Style  Semantics  and  Specification  Language 
ISOIIEC  DP  101 79,  International  Org.  for  Standardisation,  1989. 

[8]    F.C.Cole  and  H.Brown,  'ODA  modifications/extensions  version  3',  submitted  to  ISOIIEC  JTCIISC 
18/SWG,  January  1990. 

[9]     P.  J.  Brown,  'Interactive  Documentation',  in  Software  —  Practice  and  Experience,  Vol.  16,  No.  3,  pp 
291-299, 1986. 

[10]  P.  J.  Brown,  'A  Simple  Mechanism  for  the  Authorship  of  Dynamic  Documents',  in  Text  Processing 
and  Document  Manipulation,  ed  J.  C.  van  Vliet,  pp  34-42,  Cambridge  University  Press,  1986. 

[I I]  Guide:  Hypertext  for  the  Macintosh,  OWL  International  Inc.,  1986. 


-70- 


standards  for  a  Hypermedia  Database: 
Diachronic  vs.  Synchronic  Concerns 

Gregop/  Crane 
Perseus  Project 
Department  of  the  Classics 
Boylston  319 
Harvard  University 
Cambridge  MA  02138 

This  paper  outlines  the  perspectives  of  a  professor  in  one  traditional  branch  of  the 
humanities  (Classics).  My  colleagues  and  I  are  engaged  in  creating  a  hypermedia  database 
on  ancient  Greek  civilization,  but  our  work  is  intended  to  explore  the  generic  issues  of 
building  a  complex  hypermedia  database,  and  Perseus  was  conceived  as  a  model  for  what 
should  (and  no  doubt  should  not)  be  done.  We  have  encountered  a  number  of  problems 
along  the  way  that  must  be  solved  before  information  disseminated  in  a  hypermedia 
environment  can  have  more  than  marginal  impact  on  intellectual  activity.  This  paper 
addresses  h>'permedia  databases:  although  much  of  our  work  revolves  around  texts  and 
still  images,  we  can  see  that  sound,  animation,  and  motion  video  are  also  basic  categories 
of  information.  This  paper  at  least  views  hypertext  as  a  subset  of  hypermedia. 

The  argument  of  this  paper  can  be  summarized  simply.  Standai'ds  for  hypermedia 
must  emerge  before  hypermedia  databases  can  be  fully  useful,  but  long-lived  standards  can 
only  emerge  after  we  know  much  more  about  how  people  will  use  hypermedia  databases. 
Since  we  can  do  qualitatively  different  things  in  a  hypermedia  environment,  we  must 
assume  that  usage  patterns  will  emerge.  Practically  speaking,  we  can  expect  to  see  short 
term  interchange  tools  so  that  we  can  move  data  from  one  hypertext  system  to  another,  but 
we  should  be  prepared  to  abandon  these  standards  if  they  prove  too  inflexible.  The  rest  of 
this  paper  outlines  some  pragmatic  concerns. 

Standards  can  be  viewed  as  working  in  two  dimensions,  synchronic  and  diachronic. 
Synchronically,  hypermedia  standards  would  allow  all  hypermedia  systems  at  any  one  time 
to  exchange  and  share  information:  thus,  NoteCards,  HyperCard,  Intermedia,  HyperTies, 
Guide  etc.  could  aU  exchange  the  same  data.  Synchronic  standards  ai'e,  in  some  measure, 
feasible,  and  are  a  crucial  first  step.  This  paper,  however,  focuses  on  diachronic 
continuity:  the  same  hyperaiedia  database  must  be  equally  useable  now  and  for  many  years 
to  come.  In  fact,  any  hypermedia  database  that  fits  cleanly  into  any  existing  hypermedia 
system  will  probably  not  long  survive.  Synchronic  standards  will  provide  us  with 
experience  and  knowledge  that  we  can  use  to  create  truly  diachronic  standai-ds.  If  we  are 
lucky,  synclironic  will  evolve  into  diachronic,  without  shaip  breaks  in  continuity. 


-71- 


For  many,  synchronic  is  more  important  than  diachronic  continuity.  We  do  not  need 
to  preserve  for  centuries  all  the  product  documentation  for  every  computer  system  available 
in  1990.  Even  a  1970  paper  on  new  directions  in  punch  card  technology,  for  example, 
would  have  little  appeal  to  the  engineer  today.  The  Historian  of  Science  may  some  day 
wish  to  study  this  technology,  but  we  cannot  preserve  everything.  In  such  areas, 
information  must  be  disposable. 

The  notion  of  disposable  information  has  profound  implications.  If  one's  ideas  wiU 
only  be  valuable  for  five  or  ten  years  anyway,  then  the  author  may  not  care  very  much  if 
those  ideas  are  stored  in  a  hypermedia  system  that  is  itself  equally  ephemeral.  Press,  an 
early  hypertext  system  released  at  Brown  in  1971,  was  demonstrated  at  Hypertext  '89,  but 
it  appeared  there  as  an  historical  artifact  rather  than  a  living  system  (its  official  title  was  "A 
'  Blast  from  the  Past:  The  Last  (?)  PRESS  Demo".  For  others  with  a  potential  interest  in 
hypermedia  such  as  textbook  publishers,  short-lived  systems  are  ideal,  since  they  can  thus 
attack  the  used-textbook  market  and  force  students  to  buy  new  electronic  "textbooks"  with 
greater  regularity. 

It  is  hard  to  emphasize  how  destructive  such  attitudes  are.  True  publication,  however, 
implies  that  a  document  will  be  part  of  the  public  record  for  an  indefinite  period  of  time,  not 
just  for  a  few  years.  In  many  disciplines  no  scholar  can  afford  to  lavish  time  on  creating 
documents  that  will  not  last  at  least  thirty  years  and,  hopefully,  much  longer.  This  holds 
true  not  just  for  humanists  creating  tools  such  as  critical  editions  of  authors  (e.g.,  Homer, 
Chaucer),  dictionaries  and  commentaries,  but  for  many  other  areas  as  well. 
Anthropologists,  for  example,  working  in  Central  Africa  or  Latin  America  have  their  own 
questions  in  mind,  and  their  own  conclusions  may  soon  become  dated.  But  they  also 
create  ethnographic  descriptions  of  societies  that  are  rapidly  changing.  Their  pubUshed 
ethnographies  may  be  our  best  (even  our  only)  records  of  those  societies,  and  these  must 
become  permanent  part  of  our  information  infrastiucture.  We  are  constantly  adding  to  our 
basic  record  of  the  world,  and  this  record  must  be  mamtained  for  an  indefinite  future. 

The  author  who  creates  information  and  the  system  that  stores  that  information  are 
only  two  aspects  to  a  larger  whole.  Consider,  for  a  moment,  one  other  critical  group  that 
must  also  embrace  the  idea  of  hypermedia  and  for  whom  longevity  is  even  more  important. 
The  librarian  must  be  able  to  leave  information  "on  the  shelf'  for  centuries  rather  than 
decades.  No  document  will  last  long  if  it  is  not  presei'ved  as  a  regular  part  of  our  research 
library  system.  I  would  like  to  emphasize  that  a  standard  that  does  not  meet  the  most 
stringent  needs  of  research  librarians  is,  at  best,  a  crude  stopgap  and,  at  worst,  quicksand 
that  will  trap  and  overwhelm  the  unwary,  and  that  will  make  subsequent  travellers  view 
hypermedia  with  distrust. 


-72- 


The  problem  from  our  perspective  may  be  summarized  as  follows.  Hypermedia 
systems  offer  tremendous  potential  and  may  ultimately  revolutionize  the  way  in  which 
research  is  performed  and  disseminated.  Hypermedia  cannot,  however,  have  the  impact 
that  it  waiTants  until  we  can  provide  diachronic  continuity.  A  database  that  runs  on  ten 
systems  now  (and  thus  provides  synchronic  continuity)  and  zero  systems  a  decade  from 
now  does  scholar  and  librarian  little  good. 
Problem  1:    Exchanging  Data 

Exchange  standards  offer  one  obvious  approach  to  the  problem  of  diachronic 
continuity.  If  we  can  exchange  database  Fred  between  N  different  systems  at  any  one 
given  time,  then  there  is  a  high  probability  that  Fred  will  be  able  to  move  into  new  systems 
that  have  not  yet  appeared.  Fred  may  not  take  advantage  of  all  the  capabilities  of  its  new 
environment  just  as  a  black  and  white  silent  movie  does  not  exploit  the  full  capabilities  of 
the  television  on  which  it  may  be  viewed,  and  in  some  ways  performance  in  the  new 
system  may  be  weaker  (e.g.,  video  has  inherently  less  resolution  than  any  film  and  thus 
cannot  reproduce  all  the  information  in  any  one  frame  of  the  film).  But  at  least  Fred,  like 
the  silent  movie,  will  still  be  accessible. 

Converting  hypermedia  databases  from  one  system  to  another  is  much  more  complex 
than  transferring  silent  film  to  video,  more  complex,  perhaps,  than  the  problem  of 
converting  a  play  into  a  movie.  For  while  the  play  and  the  movie  have  profoundly  different 
options  open  to  them,  the  script  of  the  play  (in  most  cases)  provides  a  common  linear  path 
which  both  can  share,  and  a  movie  can  imitate  the  conventions  of  the  stage. 

The  conversion  from  one  hypertext  system  to  another  may  well  prove  more  analogous 
to  the  problem  of  machine  translation.  Existing  hypermedia  databases  and  even  standards 
for  particular  types  of  information  (such  as  the  SGML  standard  for  text)  are  generally 
closer  to  syntax  than  semantics.  They  illustrate  how  various  objects  are  put  together,  but 
they  can  only  incorporate  a  limited  amount  of  information  about  why  the  objects  are  put 
together  in  that  particular  way.  The  designers  of  the  hypermedia  database  will 
unconsciously  tend  to  rely  on  the  peculiarities  of  the  system  that  they  are  using.  Authors 
organize  their  data  differently  when  using  a  system  in  which  scrolling  windows  can  contain 
large  documents  (e.g.  Intermedia,  Notecards)  than  when  working  witli  an  inherently 
"chunky"  hypertext  system  (one  built  around  many  small  cards) 

Consider  two  examples: 

1)  HyperCard  can  easily  store  a  hierarchical  map.  The  user  begins  with  a  view  of  the 
world,  zooms  into  a  view  of  a  particular  country,  and  then  calls  up  the  plan  of  a  particular 
city.  A  user  can  implement  such  a  map  easily  with  buttons  containing  goto's,  but  will  an 


-73- 


interchange  program  be  able  to  recognize  that  these  buttons  represent,  in  fact,  a  logical 
hierarchy?  If  the  interchange  program  cannot  make  such  inferences,  will  it  produce  results 
like  the  machine  translation  system  that  interprets  "time  flies  like  an  arrow"  as  "time-flies 
enjoy  arrows"  or  as  "time  the  flies  (i.e. with  a  stopwatch)".  If  hierarchical  structures  of  one 
kind  or  another  are  to  be  a  building  block  for  hypermedia  systems,  then  all  such  systems 
must  contain  primitives  that  recognize  these  structures. 

2)  Much  discussion  has  gone  into  the  creation  of  links  between  anchors  in  various 
documents.  Document  X  would  have  a  link  to  an  anchor  in  Document  Y,  and  the  anchor 
would  identify  a  particular  point  or  selection  in  Document  Y.  This  is  a  critical  and  generic 
concept,  but,  in  some  contexts,  it  replicates  a  function  that  text  strings  implicitly  perform: 
e.g.  "Shakespeare  Macbeth  1.7.1-2  'If  it  were  done  ....  quickly"'  defines  a  precise 
subset  of  the  text.  The  text  string  is  a  high  level  construct  that  does  not  depend  upon 
anchors  into  one  particular  document:  it  wiU  work  equally  well  whether  the  Riverside 
Shakespeare  or  the  Folger  edition  of  Macbeth  is  online.  Does  an  automatic  linking  protocol 
really  constitute  an  advance  over  such  a  reference,  or  even  over  a  standard  journal  reference 
(e.g.  "HSCP  91  (1987)  175  note  60")?  If  document  (or  an  object  in  a  museum  for  that 
matter)  does  not  already  have  an  anchor  of  this  kind,  then  that  information  has  not  been 
published  in  any  meaningful  sense.  Publication  presupposes  the  existence  of  canonical 
citation  schemes.  Where  canonical  citations  schemes  do  not  exist  or  are  imperfect,  then 
information,  like  a  misshelved  book,  is  lost. 

Second,  publication  (as  in  Augment)  cannot  be  retracted.  A  statement,  once  it  has 
been  placed  in  the  public  domain  can  never  be  changed:  it  can  be  commented  on,  and  its 
author  may  recant,  but  the  statement  must  remain  a  part  of  the  record.  A  publication  system 
(as  opposed  to  an  authoring  system)  should  not  accept  vanishing  links. 

New  products  such  as  SuperCard  and  Plus  do  attempt  to  interpret  all  the  information 
within  a  HyperCard  stack,  but  only  because  their  own  model  of  the  world  is  a  superset  of 
the  HyperCard  model.  Once  a  document  is  truly  converted  to  either  SuperCard  or  Plus: 
i.e.,  once  it  takes  advantage  of  elements  in  the  SuperCard  or  Plus  model  that  are  not 
available  in  HyperCard)  then  it  cannot  easily  move  back  to  HyperCard  or  even  laterally  to 
from  SuperCard  to  Plus  or  vice  versa.  As  soon  as  hypermedia  systems  begin  to  change 
their  view  of  the  world,  then  different  systems  will  have  different  abilities.  Translating 
from  one  environment  to  another  becomes  an  interpretive  act,  in  which  human  intelligence 
may  prove  irreplaceable  for  the  forseeable  future. 

The  rest  of  this  paper  will  cover  problems  that  we  in  the  Perseus  Project  have 
encountered  in  building  a  hypermedia  database  on  ancient  Greek  civilization.  The  domain 
is  relatively  compact:  40  and  100  megabytes  of  source  texts  in  original  Greek  and  English 
translation,  a  dictionary,  a  small  encyclopedia,  essays,  maps,  plans,  and  5,000  to  10,000 


-74- 


images  of  Greek  sites,  monuments.and  art  objects  will  provide  a  solid  foundation  for  the 
study  of  this  subject.  Nevertheless,  the  problems  inherent  in  managing  such  a 
heterogeneous  database  of  this  magnitude  are  substantial. 

More  importantly,  this  data  is  intended  to  serve  a  wide  audience.  First,  it  aims  at 
different  levels  of  expertise:  the  undergraduate  in  a  general  course  and  the  professor  doing 
research.  Second,  it  aims  at  various  kinds  of  expertise:  the  same  data  should  be  useable 
for  the  study  of  literature,  art,  history,  linguistics  and  other  subjects.  In  fact,  both 
distinctions  are  related:  the  more  accessible  information  about  art  is,  for  example,  to  the 
freshman,  the  easier  it  can  be  for  literary  critics,  who  do  not  now  have  easy  access  to  that 
information,  to  use  it  in  their  work. 

Our  work  is,  to  a  large  extent,  an  experiment  within  which  we  are  trying  to  identify  the 
basic  data  structures  with  which  people  work.  Objects  such  as  dictionaries,  atiases  and 
museum  catalogue  entries  have  evolved  certain  fairly  stable  forms  that  are  based  on 
functions  that  people  seek  to  perform.  As  these  tools  migrate  into  an  electronic 
environment  they  can  perform  new  functions  and  their  forms  will  inevitably  change.  Until 
we  have  a  better  idea  of  what  these  new  functions  will  be,  however,  we  are  not  in  a  good 
position  to  build  environments  in  which  the  form  of  information  can  evolve. 

Data  Models  and  Approaches:    Some  Concrete  Problems 

Every  discipline  probably  has  its  own  proprietary  data  models  which  every  expert 
must  intemalize.  Thus,  the  mathematician  must  know  how  to  create  and  present  a  logical 
proof,  while  the  chemist  needs  to  provide  certain  kinds  of  information  when  describing  an 
experiment.  The  student  of  ancient  Greek  literature  knows  how  to  read  and  to  use  a 
scholarly  edition  of  a  Greek  text,  while  the  archaeologist  knows  how  to  work  with  objects 
discovered  on  a  dig.  Hypermedia  standards  must  provide  a  model  in  which  each  group  can 
express  as  many  significant  features  as  possible.  They  must  at  least  replicate  the 
functionality  of  printed  texts,  but  should  also  allow  people  to  perform  new  operations. 

Defining  a  data  structure  is  not  an  easy  task.  Even  if  we  have  a  model  that  satisfies 
one  group,  another  group  may  want  to  use  the  same  information  in  different  ways.  The 
following  section  provides  two  general  examples  of  the  iterative  process  that  we  have  had 
to  undergo.  The  examples  are  fairly  specific  but  they  illustrate  how  difficult  it  will  be  to 
define  what  some  people  have  in  mind  when  they  think  about  such  basic  categories  as 
archaeological  objects  and  source  texts.  Tlie  problems  below  are  very  specific,  and  domain 
experts  in  various  fields  will  have  to  create  the  actual  specifications  for  these  data 
structures.  Nevertheless,  the  standards  that  evolve  for  hypermedia  databases  wiU 
determine  how  feasible  it  is  for  the  domain  experts  to  organize  their  information.  The  more 


-75- 


effectively  authors  can  organize  their  data,  the  more  useful  the  underlying  standards  will 
prove.  Particular  and  domain  specific  as  these  problems  may  seem,  they  address 
fundamental  data  types.  Until  hypermedia  standards  provide  a  platform  that  supports  such 
data  types,  hypermedia  cannot  play  a  major  role  in  the  publication  or  the  long  term 
archiving  of  information. 

The  classicist  discussing  Greek  religion  may,  for  example,  use  the  painting  on  a  Greek 
vase  as  evidence.  He  may  point  out  that  there  is  a  man  is  leading  a  bull  to  an  altar,  that  the 
man  holds  in  his  hand  a  sacrificial  cake  and  some  barley  to  sprinkle  over  the  victim.  He 
may  draw  attention  to  the  kind  of  knife  held  or  some  other  particular  of  the  scene.  In  this 
context,  a  single  one  bit  deep  bitmap  may  well  contain  all  the  information  necessary,  and 
the  expert  in  Greek  religion  might  want  to  collect  a  large  number  of  such  images. 

The  art  historian  might  want  to  study  the  style  of  the  painter  who  created  the  picture. 
He  would  need  to  study  very  subtle  details  (such  as  the  way  in  which  anatomical  details 
such  as  eyes  or  knees  were  rendered),  but  such  detail  will  almost  certainly  lacking  in  the 
bitmap.  The  classicist  can  build  up  an  enormous  database  of  images  which  then  prove  to 
be  of  Uttle  use  to  his  or  her  colleagues  in  archaeology  or  art  history. 

Worse,  the  art  historian  may  actually  conclude  that  one  bit  deep  images  are  all  that  the 
computer  can  offer  and  thus  turn  away  from  the  new  medium.  Likewise,  many  videodiscs 
(to  choose  one  technology)  simply  imitate  image  libraries,  even  though  a  single  video 
image  cannot  approach  the  clarity  of  a  35  mm  sHde.  The  art  historian  may  thus  conclude 
that  a  videodisc  s  just  a  poor  substitute  for  a  slide  archive,  but  if  the  videodisc  designer 
takes  advantage  of  the  storage  space,  then  he  or  she  can  store  multiple  views  of  each 
complex  slide  and  can  provide  much  more  information.  A  videodisc  that  stores  details  of 
every  head  in  a  series  of  paintings  contains  information  that  the  slides  do  not,  for  the  abiUty 
to  move  directly  from  head  to  head  to  head  allows  tiie  reader  to  see  the  images  in  a  different 
way  than  would  the  undifferentiated  slides.  In  the  case  of  images,  the  media  available  to  us 
so  far  have  been  so  primitive,  that  few  of  the  scholars  who  really  care  about  art,  for 
example,  have  been  able  to  see  much  promise  in  electronic  databases  at  all. 

Suppose,  then,  one  builds  up  a  database  that  serves  the  needs  of  both  the  classicist  and 
the  art  historian.  Thus,  when  we  in  the  Perseus  Project,  for  example,  commission  new 
photography  of  an  art  object,  we  collect  multiple  views:  dozens  for  a  single  vase  with  many 
figures.  A  videodisc  thus  will  have  enough  color  \iews  so  that  it  will  allow  scholars  to  see 
more  detail  of  the  objects  on  the  disc  than  could  any  affordabe  printed  publication. 

The  case  is  not,  however,  closed.  Up  come  the  anthropologists,  also  expert  in 
handling  physical  remains.  For  them,  the  detailed  views  are  extremely  useful,  but  they 
want  to  reconstruct  day  to  day  life  of  the  period.  The  database  of  images  focuses  primarily 


-76- 


on  the  most  elegantly  painted  and  attractive  vases:  the  art  historian  wants  to  study  the 
aesthetics  of  classical  Greece;  since  carefully  drawn  and  visually  harmonious  vases  contain 
much  of  the  information  that  the  general  classicist  needs,  the  two  groups  work  well 
together.  The  anthropologist  wants  to  see  what  people  actually  used,  not  just  the  most 
polished  specimens,  but  the  coarse,  hurriedly  drawn  pieces  as  well.  Perhaps,  he  does  not 
even  want  vases  in  particular,  but  tools  and  other  objects  that  illustrate  the  kind  of  work  that 
people  performed.  Again,  the  invidual  entries  for  each  object  may  be  quite  attractive,  but 
the  anthropologist  might  argue  that  the  collection  as  a  whole  provides  a  biased  picture  of  the 
ancient  world.  Nor  are  the  anthropologist's  complaints  necessarily  limited  to  gross 
selection  of  objects:  he  or  she  have  very  different  kinds  of  questions  that  they  are  going  to 
ask  and  if  a  database  is  going  to  serve  theu'  interests,  then  its  structure  will  undoubtedly 
need  to  be  changed. 

Literary  texts  offer  similar  problems,  for  different  groups  view  texts  in  different  ways. 
The  text  of  Moby  Dick,  for  example,  is  conceived  of  as  a  fairly  stable  text  stream.  The 
critic  will  refer  to  a  particular  chapter  or  perhaps  a  page  in  a  particular  edition,  but  what 
Melville  wrote  is  clear  enough.  It  is  relatively  easy  to  build  a  publication  model  for  "text"  if 
we  think  in  terms  of  nineteenth  century  English  and  American  novels  (and  if  we  do  not 
think  too  deeply  about  the  problem). 

CHECKED  UP  TO  HERE. 

If  we  apply  this  concept  to  a  text  that  was  transmitted  in  manuscript,  this  model  is 
inadequate.  Every  time  a  large  document  is  copied  by  hand,  mistakes  appear,  and  these 
mistakes  become  compounded  with  each  new  copy.  Over  the  course  of  centuries,  many 
variant  forms  of  the  text  evolve  and  only  with  the  printing  press  can  this  process  of 
dissolution  be  arrested.  Nevertheless,  the  damage  is  done:  editors  must  choose  between 
many  competing  variants,  and  must  tell  the  reader  when  they  choose  a  reading  from 
manuscript  X  or  Y,  The  reader  needs,  at  a  minimum,  to  see  what  variants  are  available  for 
any  passage  of  text.  Ideally,  the  system  should  be  able  to  show  the  reader  where  editor  A 
chooses  different  readings  from  editor  B,  or  to  show,  for  example,  which  corrections  in  the 
text  were  suggested  before  1800. 


^^^^aniiscript  0 


Scholarly 

Edition 

Manuscript  1  J 


—ii.rBMii  ■■■wimiwumMUPiiiaiii^^'^t— I 

Manuscript  n 


-77- 


Figure  1:  Simplified  view  of  a  scholarly  edition  derived  from 
various  "manuscripts".  Every  line  of  text  may  involve  an 
"editorial  selection." 

Again,  addressing  both  the  nineteenth  century  novel  and  ancient  Greek  literature  forces 
us  to  broaden  our  model  of  what  a  text  is.  Nevertheless,  we  are  not  finished.  Consider  a 
popular  text  that  appears  in  various  forms  over  a  number  of  centuries.  In  the  case  of  the 
Greek  poet  Aeschylus,  for  example,  we  assume  that  there  is  an  original  source  text  (i.e., 
what  Aeschylus  aclaially  wi-ote)  that  we  are  trying  to  reconstruct.  Ideally,  we  could  treat 
Aeschylus  like  Melville  if  we  had  an  authoritative  edition  of  Aeschylus.  In  the  case  of  a 
popular  story,  we  may  have  multiple  versions,  none  of  which  is  associated  with  any 
dominant  owner  and  each  of  which  is  essentially  just  as  important  as  the  others.  Each 
version  of  the  story  may  itself  have  its  own  manuscript  tradition,  but  now  we  must 
consider  a  kind  of  compound  versioning:  a  story  consisting  of  multiple  versions  each  of 
which  has  numerous  textual  variants. 


Figure  2:  A  compound  text,  consisting  of  n  scholarly  texts  (each 
of  which  may  be  constructed  from  a  variety  of  manuscripts). 

On  the  other  end,  even  the  category  of  "manuscript"  is  not  completely  simple.  A 
document  may  be  preserved  on  a  stone  or  clay  tablet.  The  writing  system  used  to  store  this 
text  may  be  crude,  and  scholars  may  need  to  provide  normalized  transliterations  that  follow 
conventional  spelling  rules  or  add  some  standard  kind  of  information  (thus  many  editors  of 
Greek  inscriptions  add  accents  to  theii;  final  editions).  In  such  cases,  an  edition  may 
include  (1)  a  picture  of  the  inscription,  (2)  a  transliteration  of  the  inscription  without  accents 
or  word  breaks  that  simply,  (3)  a  regulariized  form.  The  physical  medium  may  be  stone  or 
(as  in  the  case  of  much  AJckadian  and  Sumerian  material)  clay  tablet,  but  in  many  ways  the 
problem  is  similar  to  that  faced  by  someone  transcribing  a  sound  recording  made  by  the 
speaker  of  a  little  known  language.  The  ethnographer  may  well  want  to  include  a  narrow 


-78- 


phonemic  transliteration.  Thus,  we  might  outhne  the  structure  of  a  source  document  (of 
which  a  "manuscript"  is  one  example)  as: 


Normalized 

Narrow 

Transliteration 

Transcription 

-|  Recording 


Picture  of 
Inscription 


Sound 
Recording 


Figure  3:  Diagram  for  one  taxonomy  of  source  documents  (such 
as  a  manuscript  or  inscription). 


This  diagram  presents  a  basic  data  model  that  will  solve  many  of  the  problems  for 
storing  nineteenth  century  novels,  Greek  plays,  Akkadian  myths,  Greek  and  Akkadian 
inscriptions,  and  an  anthropologist's  verbal  recordings  made  in  the  field. 

The  particulars  of  this  simpUfied  model  are  less  important  than  the  process  that  led  to 
its  creation:  had  we  standardized  around  the  nineteenth  century  novel,  the  Greek  play  or 
the  inscription,  we  would  have  adopted  an  impoverished  data  model.  We  need  to  view  in 
as  much  detail  as  possible  as  many  different  kinds  of  text  as  we  can  before  we  assume  that 
we  know  what  a  text  is  or  what  it  can  do.  A  system  that  can  handle  these  functions  must 
address  links  not  simply  from  one  document  to  another,  but  between  text,  pictures,  sound 
and  motion  video.  Until  we  have  systems  that  actually  perform  these  tasks,  we  will  not  be 
sure  that  our  standards  actually  account  for  the  problems  that  people  need  to  solve.  This 
kind  of  analysis  has  barely  begun,  and  we  have  a  long  way  to  go  before  we  reach  any 
consensus  as  to  how  any  basic  categories  of  informadon  should  be  organized. 
Hybrid  Data  models 

So  far  we  have  talked  about  simple  data  types  that  have  analogues  in  the  world  of 
print.  We  can  insulate  the  individual  components  of  data  from  the  vagaiies  of  any  one 
system  by  storing  information  in  the  most  powerful  medium  possible.  Thus,  we  at  Perseus 
have  pragmatically  chosen  to  expend  extra  effort  so  that  our  information  will  be  useful  for  a 
longer  period  of  time:  drawings  are  stored  not  as  bitmaps  but  in  Postscript;  for  still  images 
we  use  35  mm  film  rather  than  video.  A  single  Postscript  can  generate  multiple  bitmaps  at 
varying  resolutions,  and  whatever  the  future  of  Postscript  itself,  subsequent  graphic 
formats  will  probably  be  able  to  absorb  most  of  the  existing  Postscript  data.  We  will  thus 
be  able  to  upgrade  our  site  plans  and  drawings  to  systems  that  do  not  rely  on  bitmaps. 
Slides,  though  not  electronic,  contain  far  more  infonnation  than  we  can  now  reasonably 


-79- 


store  in  digital  form.  Should  new  formats  such  as  HDTV  actually  arrive  within  the  next 
five  to  ten  years,  film  will  convert  much  more  elegantly  than  inherently  crude  NTSC  video 
signals  with  their  limited  resolution.  None  of  the  hypermedia  or  hypertext  systems 
currently  available  can  recognize  sophisticated  text  structures  that  one  can  create  in  format 
such  as  SGML,  but  we  store  our  texts  in  SGML  and  will  be  able  to  take  advantage  of  more 
powerful  hypertext  systems  as  these  emerge. 

Efforts  are  ab"eady  underway  to  provide  workable  standards  in  at  least  some  of  these 
individual  areas.  The  Text  Encoding  Inidative,  funded  primarily  by  the  NEH  and  EEC,^  is 
a  widely  supported  effort  to  build  basic  document  formats  for  humanists  within  the 
framework  of  SGML.  Storing  images  as  slides  or  as  postscript  drawings  is  a  pragmatic 
hedge  rather  than  a  workable  standard. 

Work  on  texts  or  images  in  isolation  is  only  part  of  the  problem,  for  these  are  only 
some  of  the  basic  components  out  of  which  a  hypermedia  documents  might  be  constructed. 
Once  we  know  how  to  handle  these  individual  pieces,  a  hypermedia  system  must  then  be 
able  to  make  the  individual  pieces  work  together  as  a  whole.  If  an  historical  source  text,  an 
atlas  and  a  database  of  topographical  images  (i.e.,  pictures  showing  buildings  and  places) 
all  exist  in  the  same  database,  then  it  can  become  much  easier  for  the  person  going  through 
the  historical  document  to  locate  places  on  a  map  and  even  to  call  up  images  of  what  that 
place  looks  like  now.  Someone,  for  example,  reading  in  the  Greek  historian  Herodotus 
about  how  the  Greeks  defeated  the  Persians  in  the  battle  of  Salamis  might  thus  call  up  a 
map  on  which  Salamis  appears,  then  view  color  images  of  the  strait  in  which  the  battle  was 
fought  or  the  hilltop  from  which  Xerxes,  the  Persian  emperor,  viewed  the  battle. 

Once  traditionally  discrete  bodies  of  knowledge  such  as  text,  atlas  and  image  archive, 
can  dynamically  interact  with  one  another,  then  new  compound  document  types  become 
feasible.  A  narrative  on  the  batde  of  Salamis  might  consist  of  (1)  links  to  the  relevant  text 
sources,  (2)  a  map  of  Salamis  with  various  buttons  which  were  in  turn  (3)  links  into  the 
image  archive  showing  what  the  strait  of  Salamis  or  the  hilltop  of  Xerxes  looks  like.  Nor 
should  such  links  be  entirely  passive:  an  animated  version  of  the  battle  could  be  overlayed 
onto  the  generic  map.  Rather  than  calling  up  an  entire  picture,  the  system  should  be  able  to 
crop  a  particular  detail,  so  that  the  view  frames  that  particular  hill,  for  example,  on  which 
Xerxes  may  have  sat.  A  document  may  dynamically  abstract  and  shape  data  from  a  larger 
data  base. 

Such  interactive  and  dynamic  links  fulfill  logical  needs  and  will  inevitably  become  pait 
of  tiie  autiior's  repertoire.  An  autiior  should  be  able  to  create  a  document  tiiat  pulls  together 

^The  Project  Director  for  this  is  Dr.  C.  Michael  Sperberg-McQueen,  of  the  University  of  Illinois  at 
Chicago  Circle. 


-80- 


and  performs  operations  on  material  in  a  larger  database.  It  is  not  enough,  however,  to  be 
able  to  perform  such  actions  in  a  particular  system  in  a  particular  time.  Once  an  author  has 
published  such  a  hypermedia  document  (perhaps  as  part  of  a  book  interpreting  the  wars 
between  the  Greeks  and  Persians),  then  scholars  a  century  later  must  be  able  to  view  that 
hypermedia  document  and  see  exactly  what  the  author  saw.  If  this  diachronic  continuity  is 
not  feasible,  then  the  hypermedia  document  may  have  been  distributed  but  cannot  properly 
be  said  to  have  been  "published".  True  publication  implies  that  the  material  will  remain 
available  for  the  indefinite  future. 
Conclusions 

We  should  move  as  quickly  as  we  can  towards  some  kind  of  synchronic  interchange 
standard  for  hypermedia.  We  need  to  learn  how  well  we  can  move  fairly  complex  sets  of 
data  and  functionality  between  diverse  systems  (e.g.  HyperCard,  Intermedia,  Notecards). 
Once  we  are  able  to  perform  this  task  for  some  data,  we  may  well  decide  that  the 
interchange  format  that  developed  is,  in  fact,  too  inflexible.  With  luck,  this  interchange 
format  will  be  a  powerful  platform  that  can  evolve  into  a  standard  that  wiU  provide  scholars 
and  archivists  with  the  diachronic  continuity  that  they  require.  We  must,  however,  be 
prepared  to  discard  that  format. 

The  risk  is  probably  greatest  for  those  of  us  creating  databases:  until  we  have 
diachronic  standards,  the  information  that  we  create  may  be  available  in  libraries,  but  it  will 
not  be  part  of  the  library  system.  It  will  be  distributed,  but  not  truly  "published." 
Nevertheless,  we  cannot  make  much  progress  on  standards  without  applying  them  to 
substantial  and  fairly  complex  bodies  of  data. 

From  a  practical  point  of  view,  we  suggest  that  those  developing  interchange  standards 
should  plan  to  work  from  the  beginning  with  one  or  more  databases  at  least  as  large  and 
complex  as  that  of  the  Perseus  Project.  An  interchange  system  that  can  move  this  database 
back  and  forth  between  three  or  more  different  hypermedia  systems  may  not  be  perfect,  but 
an  interchange  system  that  cannot  satisfy  tliis  practical  requirement  will  certainly  not 
support  the  much  greater  challenges  that  it  will  face. 


-81- 


The  Trellis  Hypertext  Reference  Model 

Richard  Furuta*  and  P.  David  Stotts 
Department  of  Computer  Science 
University  of  Maryland 
College  Park,  MD  20742 


Abstract 

We  describe  a  hypertext  "meta- model" — one  that  provides  an  organization  for  the  architec- 
ture of  a  hypertext  model.  The  specific  meta-model  presented  was  developed  in  the  context 
of  the  Trellis  hypertext  model.  However  the  organization  seems  generally  applicable  to  other 
models  as  well.  As  such  the  meta-model  may  be  a  good  candidate  for  a  hypertext  reference 
model,  and  so  we  call  it  the  Trellis  hypertext  reference  model.  In  this  report  we  first  describe  the 
Trellis  hypertext  reference  model,  and  then  discuss  the  relationship  of  some  hypertext-defined 
concepts  to  the  reference  model. 

1  Introduction 

As  a  side-product  of  our  work  developing  the  Trellis  model  of  hypertext  [SF89a],  we  have  defined 
a  "meta-model"  that  provides  an  organization  for  the  architecture  of  the  hypertext  model.  It  is 
the  purpose  of  this  report  to  describe  this  meta-model  within  the  context  of  the  Trellis  model  and 
further  to  suggest  that  it  is  applicable  to  other  models  of  hypertext  as  well.  As  such  it  may  serve 
as  an  appropriate  framework  for  the  development  of  a  general  hypertext  reference  model.  In  this 
report  we  shall  call  the  "meta-model"  the  Trellis  hypertext  reference  model,  abbreviated  as  r-model, 
as  a  reflection  of  this  application.  The  model  of  hypertext  itself  will  be  called  the  hypertext  model, 
or  more  simply  the  model  throughout  the  report. 

The  Trellis  hypertext  reference  model  is  based  around  a  collection  of  representations  of  the 
hypertext  at  different  levels  of  abstraction.  Abstractions  range  from  the  hypertext  as  a  collection 
of  abstractly- defined  independent  components  through  more  concrete  representations  in  which  the 
characteristics  of  the  hypertext's  physical  display  have  been  established,  to  the  view  of  the  hypertext 
that  is  projected  on  a  physical  display  device  for  the  benefit  of  the  person  reading  the  hypertext. 
The  representations  at  a  particular  level  of  abstraction  depend  upon  representations  at  a  greater 
level  of  abstraction,  and  these  dependencies  are  shown  within  the  r-model. 

A  description  of  the  r-model  follows  in  the  next  section.  Section  3  discusses  how  selected 
components  of  existing  hypertext  systems  and  models  fit  into  (or  are  omitted  from)  the  r-model. 

'Supported  in  part  by  a  grant  from  the  National  Science  Foundation,  CCR-8810312. 


-83- 


Abstract  Component  Level 


Structure 


Abstract 
Contents 


Content-Structure 
Associations 


Abstract 
Buttons 


Button-Structure 

Associations 


Abstract 
Containers 


Abstract  Hypertext  Level 


Container-Structure 

Associations 


Concrete  Hypertext  Level 


Concrete 
Windows 


Visible  HT 
Segment 


Visible  HT 
Segment 


Visible  HT 
Segment 


User  Display  User  Display  User  Display 

Figure  1:  The  Trellis  Hypertext  Reference  Model  (the  r-model) 


-84- 


2    The  r-model 


The  r-model,  shown  symbolically  in  Figure  1,  is  separated  into  five  logical  levels.  Within  each 
level  is  found  one  or  more  representations  of  part  or  of  all  of  the  hypertext.  Speaking  quite 
broadly,  the  levels  may  be  grouped  into  three  overall  categories:  abstract,  concrete,  and  visible.^ 
The  abstract  component  and  abstract  hypertext  levels  define  an  abstract  representation  of  the 
pieces  of  the  hypertext  and  of  the  hypertext  itself.  These  abstractions  are  transformed  into  more 
concrete  representations  of  the  hypertext  in  the  concrete  context  and  concrete  hypertext  levels, 
representing  first  the  presentation  of  the  hypertext's  content  and  then  the  mapping  of  that  content 
into  the  displayed  windows.  The  resulting  concrete  windows  are  then  viewed,  producing  one  or 
more  displays  on  one  or  more  physical  display  devices.  In  summary,  the  representations  in  the 
abstract  component  level  are  at  the  greatest  level  of  abstraction  and  those  in  the  visible  hypertext 
level  are  at  the  lowest  level. 

Each  representation  is  shown  in  the  figure  as  a  box.  A  representation  is  itself  an  abstract 
concept — a  consistent  presentation  of  the  hypertext  elements  of  interest.  Representations  in  the 
r-model  may  depend  on  the  representations  at  a  greater  level  of  abstraction.  Such  a  dependency  is 
shown  in  the  figure  as  an  arc  between  the  representations.  Because  a  representation's  dependencies 
are  on  those  representations  at  a  greater  level  of  abstraction,  and  not  on  those  at  the  same  or  lower 
levels  of  abstraction,  the  abstract  and  concrete  levels  in  the  diagram  are  further  subdivided.  It  is 
worth  emphasizing  that  a  representation  may  not  actually  correspond  to  a  separately-identifiable 
"physical"  representation  of  the  hypertext;  for  example,  the  representation  may  be  expressed  as  a 
mapping  between  elements  of  more  abstract  representations. 

We  will  now  focus  in  turn  on  each  of  the  levels  of  the  r-model.  In  the  following  sections,  we  will 
describe  the  level,  its  representations,  and  discuss  the  dependencies  on  representations  at  higher 
levels. 

2.1     Abstract  hypertext 

An  abstract  hypertext  description  specifies  a  hypertext  and  its  components,  but  does  not  describe 
the  details  of  how  the  hypertext  is  to  be  presented  to  its  reader. 

2.1.1     Abstract  component  level 

The  organization  of  the  three  highest  levels  reflects  a  separation  of  the  hypertext  into  structure, 
content,  and  context.  The  structure  represents  the  elements  of  the  hypertext  and  their  relationships. 
The  specific  content  of  the  hypertext  as  presented  to  the  system's  user  reflects  the  context  within 
the  structure  in  which  the  content  appears — in  other  words,  the  display  of  the  content  is  modified 
to  reflect  its  context. 

The  representations  within  the  abstract  component  level  present  the  components  that  will  be 
associated  with  one-another  to  form  the  hypertext.  Within  the  context  of  this  level,  the  representa- 
tions are  independent  of  each  other — such  associations  will  be  made  at  lower  levels  of  abstraction. 
Our  abstract  view  of  a  hypertext  separates  out  the  hypertext's  structure  from  the  elements  that 
many  users  perceive  as  composing  the  hypertext.  In  other  words,  the  structure,  perhaps  a  directed 
graph,  is  separated  from  the  collection  of  contents  that  are  to  be  displayed  to  the  reader  and  the 

^The  choice  of  these  levels  of  representation  parallels  and  expands  Shaw's  model  of  printed  documents  [ShaSO] 
which  identifies  abstract,  concrete,  and  viewing  mappings  for  the  document. 


-85- 


collection  of  "buttons"  that  will  be  selected  by  the  reader  when  moving  from  location  to  location 
in  the  hypertext.  Additionally,  it  may  be  the  case  that  the  view  of  the  hypertext  presented  to  the 
reader  combines  together  independent  content  elements  into  an  integrated  whole.  The  presence  (or 
absence)  of  such  composition  is  also  represented  abstractly  at  this  level.  We  will  now  consider  each 
of  the  representations  in  turn. 

One  natural  representation  for  the  structure  of  the  hypertext  is  as  a  network.  In  our  own 
work,  we  use  a  Petri  net  structure,  which  provides  automaton  semantics  as  well  as  the  network  rep- 
resentation. However  other  graph-based  structures  are  appropriate  as  well — for  example  automata 
such  as  deterministic  finite  automata  or  data  structures  such  as  directed  graphs,  trees,  or  lattices. 
The  structure  of  the  hypertext  need  not  be  limited  to  networks;  indeed,  it  may  be  desirable  to  use 
representations  that  are  not  graph-based  in  form;  for  example  constraint-based  descriptions.  Note 
that  even  in  graph-based  representations,  there  is  no  requirement  that  the  elements  of  the  structure 
be  fully-connected.  The  necessary  characteristics  of  the  structure  representation  is  that  it  provides 
the  "placeholders"  that  will  be  associated  with  the  hypertext's  content  and  that  it  describes  the 
relationships  that  exist  among  these  placeholders. 

The  abstract  content  is  arbitrary  in  form.  It  may,  for  example,  include  textual,  graphical, 
animated,  or  perhaps  even  audio  and  video  material.  The  content  may  be  specified  directly  or 
may  be  the  result  of  a  computation.  While  it  does  not  contain  links,  it  may  incorporate  markers 
that  define  a  collection  of  potential  locations  for  the  mappings  of  links  and  their  presentations  that 
occur  in  lower  levels  of  the  r-model.  The  content  may  be  described  in  a  form  that  is  independent 
of  the  eventual  characteristics  of  its  display,  or  indeed  it  may  be  described  in  a  form  that  is  highly 
dependent  on  the  eventual  display.  Because  of  the  flexibility  of  the  mapping  from  content  to 
structure  in  the  next  level,  however,  a  display-independent  representation  seems  most  appropriate. 

The  structure  representation  identifies  the  relationships  among  content  elements  but  does  not 
indicate  how  those  relationships  will  be  shown  for  selection  by  the  hypertext's  reader.  The  abstract 
buttons  are  abstractions  of  the  ways  in  which  the  relationship  can  be  displayed.  Abstract  buttons 
may  themselves  have  content  and  an  associated  type.  The  content  is  provided  to  specify  what  will 
be  shown  when  the  button  is  displayed.  The  type  is  needed  to  specify  how  the  button  will  be 
displayed  and  other  characteristics  of  its  behavior  on  display  and  selection.  As  with  the  content  of 
the  abstract  content,  the  content  of  the  abstract  button  is  variable  in  form — in  implementation  it 
actually  may  be  computed  or  it  may  be  statically  defined. 

The  final  component  in  this  level,  the  abstract  containers,  differs  from  the  others  in  that  it 
is  an  abstraction  of  how  the  pieces  of  the  hypertext  will  be  combined  when  shown  to  the  reader 
{how  it  will  be  aggregated  and  combined  for  display),  and  not  of  what  is  in  the  hypertext.  For 
example,  if  several  content  elements  are  displayable,  one  possible  presentation  would  be  to  show 
each  element  separately  while  another  would  be  to  combine  the  separate  elements  into  a  composite, 
which  would  be  presented  to  the  reader  as  a  unit.  In  the  first  case,  one  could  say  that  a  separate 
container  had  been  associated  with  each  separate  content  element,  while  in  the  second  case,  one 
container  would  hold  all  content  elements.  Such  characteristics  are  abstracted  at  this  level  by  the 
abstract  containers. 

2.1.2     Abstract  hypertext  level 

The  elements  of  the  abstract  component  level  are  not  connected  together,  as  will  be  necessary  to 
form  a  hypertext.   This  association  is  performed  in  the  abstract  hypertext  level.   The  abstract 


hypertext  level  does  not,  however,  describe  how  these  associations  will  be  presented  within  the 
display  of  the  hypertext.  This  is  left  to  the  concrete  context  level. 

The  content-structure  associations  map  together  elements  of  the  structure  and  elements  of 
the  abstract  content.  In  a  graph-based  structure,  one  natural  association  is  to  map  the  content  ele- 
ments to  the  nodes  of  the  graph.  No  restriction  is  expressed  in  the  r-model  on  the  kinds  of  mappings 
that  are  permissible — for  example  it  may  be  useful  to  map  a  single  content  element  to  multiple 
locations  in  the  structure,  or  conversely  to  map  multiple  content  elements  to  a  single  location.  In 
our  own  work,  we  have  found  the  ability  to  map  a  single  content  element  to  multiple  locations 
to  be  particularly  useful.  We  have  also  found  it  useful  to  completely  substitute  a  new  collection 
of  abstract  contents  and  of  content-structure  associations  while  retaining  the  same  structure — for 
example  for  related  hypertext  versions,  where  one  may  perhaps  be  a  translation  of  the  other. 

The  button-structure  associations  map  the  structure's  relationship  and  abstract  buttons. 
A  natural  association  in  a  graph-based  structure  is  to  map  the  abstract  buttons  to  arcs  in  the 
graph.  In  our  Trellis  hypertext  model,  based  on  Petri  nets,  the  mapping  is  between  the  class  of 
node  called  a  transition  and  the  abstract  buttons  (i.e.,  there  is  no  mapping  of  arcs  in  this  particular 
graph  structure).  Again  we  emphasize  that  there  are  no  limitations  expressed  on  the  form  of  the 
mapping,  although  we  have  found  a  one-to-one  mapping  to  be  the  most  useful. 

Finally,  the  container-structure  associations  describe  the  association  of  the  structure,  or 
of  portions  of  the  structure,  to  one  or  more  abstract  containers.  One  use  of  this  association  is  to 
permit  grouping  of  elements  of  the  structure,  which  might  in  turn  be  displayed  to  the  reader  in  a 
single  physical  window.  Different  kinds  of  composite  displays  would  be  represented  as  associations 
with  different  types  of  abstract  containers.  In  general,  the  container-structure  associations  allow 
the  partitioning  of  the  subsequent  display  of  the  hypertext  into  one  or  more  possibly  overlapping 
pieces. 

2.2    Concrete  hypertext 

Assume  that  a  hypertext  is  presented  to  its  reader  or  readers  in  one  or  more  windows  on  one  or 
more  physical  display  devices.'^  A  concrete  hypertext  description  specifies  what  the  contents  of 
each  of  these  windows  will  look  like  but  does  not  tie  down  how  the  windows  are  to  be  arranged 
on  the  display.  For  example,  one  particular  window  may  be  shown  on  several  separate  displays. 
Furthermore,  the  characteristics  of  the  displays  may  be  different;  in  this  case  the  subsequent  viewing 
description  will  also  indicate  how  the  different  visible  effects  specified  by  the  concrete  description 
are  to  be  rendered  on  the  displays. 

2.2.1     Concrete  context  level 

The  previously-described  levels  have  defined  an  abstract  hypertext  in  which  the  content  and  the 
buttons  have  been  associated  with  the  structure.  However,  the  abstract  hypertext  description  does 
not  indicate  how  links  are  to  be  presented  in  the  display  of  the  content.  Such  considerations  of  the 
mapping  from  the  hypertext's  abstract  representation  to  its  physical  representation  are  addressed 
in  the  concrete  context  level. 

The  concrete  content  presents  a  physically-oriented  description  of  the  hypertext.  This  mapping 
must  a,ddress  the  following  points: 

^Here  a  window  contains  a  concrete  view  of  the  hypertext  (or  portion  of  the  hypertext)  to  be  presented  to  the 
reader. 


-87- 


How  is  the  abstract  content  to  be  formatted  to  fit  within  the  display  region? 


•  How  are  the  buttons  to  be  displayed?  Will  the  display  of  the  button  modify  the  display  of 
the  content  or  will  the  buttons  and  content  be  displayed  independently?  For  example,  in 
our  initial  Trellis  prototype  (ctTrellis),  we  have  provided  externally  represented  buttons.  In 
our  subsequent  prototype  (xTrellis),  we  have  also  developed  means  for  specifying  that  the 
button  is  to  be  represented  as  a  highlighted  string  within  textual  context  [FS89a].  Note  that 
button  displays  are  not  necessarily  static;  in  some  cases  the  display  of  the  button  depends  on 
computed  material  (which  itself  may  depend  on  the  structural  relationships  in  the  hypertext). 
The  button  represents  the  source  of  a  link  in  the  hypertext.^ 

•  Is  the  target  of  a  link  associated  with  a  content  element  as  a  whole,  or  is  it  associated  with 
a  particular  location  within  that  content?  Does  the  display  of  the  target  affect  the  display  of 
the  content? 

The  mappings  on  this  level  do  not  rely  directly  on  the  structure  (abstract  component  level)  because 
the  structural  relationships  have  been  "encoded"  into  the  representations  of  the  abstract  hypertext 
level. 

2.2.2    Concrete  hypertext  level 

The  concrete  context  level  has  defined  a  set  of  concrete  content  elements  in  which  a  concrete 
representation  of  the  content  has  been  merged  with  concrete  representations  of  the  buttons.  The 
concrete  hypertext  level  maps  those  concrete  representations  into  a  set  of  windows  for  display.  The 
mapping,  which  produces  the  concrete  windows  representation,  also  requires  that  link-based 
interrelationships  among  the  windows  be  determined.  For  example,  the  process  of  following  a  link 
can  result  in  several  different  display  mappings:  the  display  of  the  target  of  the  link  could  replace 
the  display  of  the  source,  could  be  shown  in  addition  to  the  source,  or  could  modify  the  display  of 
the  source,  with  both  being  shown  in  the  same  window. 

When  the  concrete  windows  representation  has  been  formed,  the  presentation  of  the  hypertext 
has  been  determined  but  the  details  of  how  and  where  the  windows  are  to  be  displayed  has  not.  For 
example,  multiple  windows  may  be  shown  to  a  single  reader  on  a  display  or  a  particular  window 
may  be  shown  to  several  reader  simultaneously  on  separate  displays.  Indeed,  a  particular  reader 
may  have  several  physical  displays  at  his  disposal,  and  different  displays  may  have  equivalent  but 
different  means  for  achieving  particular  visual  effects.  Such  considerations  are  addressed  in  the 
next  level. 

2.3    Displayed  (visible)  hypertext 

The  details  of  the  mapping  from  the  concrete  hypertext  to  the  visible  presentation  of  the  hypertext 
for  the  reader  are  specified  here.^  However,  user  interface  details,  such  as  the  positioning  and  sizing 
of  windows,  are  orthogonal  to  the  r-model,  as  discussed  later  in  this  report. 

■^See  also  the  comparison  with  anchors  that  follows  in  section  3.1.2. 

•  "Visible  presentation"  is  a  simplification,  since  the  presentation  is  not  limited  to  being  visible.  For  example,  it 
might  be  audible,  etc. 


-88- 


2.3.1    Visible  hypei'text  level 

An  assuinption  in  the  r-model  is  that  the  underlying  hypertext  is  to  be  permitted  to  be  used  in  a 
distributed  environment.  The  visible  hypertext  level  reflects  this  assumption.  Each  visible  HT 
segment  is  associated  with  a  separate  user  and  display.  Each  segment  presents  one  or  more  of 
the  active  concrete  windows  to  its  viewer.  The  model  does  not  prevent  the  display  of  a  particular 
concrete  window  in  more  than  one  segment.  Whether  (and  how)  the  effects  of  user  interactions  to 
one  display  may  affect  what  is  shown  on  other  user  displays  is  a  property  of  the  hypertext  model, 
and  not  of  the  r-model. 

3    Issues  in  application  of  the  r-model 

We  now  turn  our  attention  to  three  aspects  of  the  r-model,  which  we  shall  consider  in  detail.  In 
Section  3.1,  we  discuss  some  important  components  of  hypertext  systems  and  how  they  fit  into  the 
r-model.  In  Section  3.2,  we  turn  our  attention  to  central  issues  in  implementation  of  a  hypertext 
system  that  are  orthogonal  to  our  model- centered  r-model.  Finally,  in  Section  3.3,  we  discuss  the 
intersection  of  our  r-model  with  already-existing  defined  and  defacto  standards. 

3.1     Further  discussion  of  elements  of  the  r-model 

A  number  of  structures  and  components  have  been  identified  for  hypertexts.^  Here,  we  present 
some  of  these  hypertext  elements  and  describe  their  categorization  within  our  reference  model. 

3.1.1  Hypertext  model  structures 

We  emphasize  that  the  hypertext's  abstract  structure  is  arbitrary  in  form  within  the  reference 
model.  It  may  be  graph-based,  describing  only  object  interrelationships,  or  it  may  also  have 
automaton  semantics.  It  need  not  be  homogeneous  in  form;  heterogeneous  structures  may  be 
appropriate  for  some  applications.  It  need  not  be  static  in  form  but  may  be  dynamic.  Indeed,  it 
need  not  be  explicitly  computed  or  represented.  What  is  required,  however,  is  that  it  be  possible 
to  intuit  where  it  is  possible  to  include  content  in  the  hypertext  and  also  the  relationships  between 
elements  of  the  content. 

3.1.2  Anchors 

In  some  other  models  of  hypertext,  anchors  have  been  identified  as  separatable  component  of 
a  hypertext.^  The  anchor  represents  the  terminating  point  or  points  of  a  link.  In  one  general 
form,  anchors  may  be  associated  with  both  the  source  and  the  target  of  a  one-directional  link  in 
a  hypertext.  They  present  the  relationship  between  the  identified  portion  of  the  source  and  the 
identified  portion  of  the  target.  In  other  implementations,  anchors  are  only  associated  with  source, 
with  the  target  being  the  node  as  a  whole.  In  our  Trellis  implementations,  anchors  may  or  may 
not  be  associated  with  the  source — when  no  anchor  is  associated  with  a  source  then  the  link  is 
represented  by  a  (graphical)  button  in  a  separately  displayed  palette. 

^See  [LSK88],  for  example,  for  definitions  of  related  terminology. 
®See,  for  example,  the  Dexter  reference  model  [HS90]. 


-89- 


Within  the  r-model,  the  display  of  anchors  in  source  and  target  is  specified  in  the  mapping  that 
defines  the  concrete  content  (concrete  context  level).  Both  the  form  of  the  display  and  also  its 
position  are  described  here.  Issues  involving  positioning  of  the  target  content's  display  when  a  link 
is  followed  are  addressed  in  the  definition  of  the  concrete  windows  (concrete  hypertext  level). 

3.1.3  Different  flavors  of  links 

A  hypertext  implementation  may  contain  several  different  kinds  of  links,  each  with  a  different 
implemented  action  on  selection.  The  distinction  between  the  different  types  of  link  is  reflected  in 
the  r-model  by  a  difference  between  the  types  of  their  corresponding  abstract  buttons. 

The  display  of  the  source  or  target  of  a  link  may  be  static  or  may  be  computed.  Such  displays 
are  described  within  the  mapping  that  produces  the  concrete  content  representation. 

In  some  circumstances  selection  of  a  link  may  cause  an  apparent  change  to  the  displayed  content, 
for  example,  insertion  of  the  target's  content  into  place  in  the  source.  When  the  content  actually 
changes  in  form,  this  is  a  matter  of  interest  in  the  concrete  content.  However,  when  the  content  is 
actually  unchanged  in  form,  as  is  the  case  when  the  target  material  is  inserted,  this  can  be  described 
through  the  display  mapping  that  produces  the  concrete  windows  representation. 

3.1.4  Dynamic  content 

Abstract  content  may  be  statically  defined  or  it  maj^  be  computed.  It  is  useful  to  distinguish 
separate  categories  of  computed  content  from  one  another.  One  such  categorization  distinguishes 

•  Computed  content:  executor  of  an  algorithm  that  produces  a  subsequently  static  display 

•  Dynamic  content:  Dynamic  execution  of  an  algorithm:  start  on  node  entry,  terminate  on 
node  exit 

•  Filtered  computation:  Continuously-executing  filter 
3.2     Orthogonal  considerations 

The  r-model  is  centered  around  organizing  and  categorizing  the  parts  of  a  model  of  hypertext. 
Consequently,  there  are  elements  of  an  implementation,  as  well  as  elements  of  some  hypertext 
models,  that  are  not  included  in  the  r-model.  These  will  be  presented  in  this  section  of  the  report. 

3.2.1     Hypertext  browsing  semantics 

We  have  previously  defined  a  hypertext  system's  browsing  semantics  [SF89a]  as  the  dynamic  prop- 
erties of  a  reader's  experience  when  browsing  a  document;  in  other  words,  as  the  manner  in  which 
the  information  within  the  hypertext  is  to  be  visited  and  presented.  In  most  cases,  browsing  seman- 
tics are  specified  by  the  code  that  implements  the  hypertext  system.  However,  it  is  also  possible 
to  develop  a  hypertext  model  with  variable  browsing  semantics;  for  example  our  Trellis  hypertext 
model  permits  specification  of  the  hypertext's  browsing  semantics  [FS89b].^  Although  specifiable 

'^The  behaviors  associated  with  different  link  types  are  reflected  by  their  browsing  semantics.  Consequently, 
variable  browsing  semantics  are  the  implementation  mechanism  for  user-defined  link  types,  as  well  as  other  browsing 
behaviors. 


-90- 


browsing  semantics  are  in  some  hypertext  models,  they  are  not  in  all,  and  so  we  have  decided  not 
to  include  them  directly  in  the  r-model. 

Similarly,  we  have  not  included  the  hypertext's  dynamic  behavior  in  the  r-model.  By  dynamic 
behavior,  we  mean  those  cases  in  which  a  hypertext  system  traverses  the  structure  without  inter- 
vention from  the  reader  [SF89b].  Dynamic  behavior  is  distinct  from  dynamic  content,  however.  As 
noted  above,  dynamic  content  is  described  within  the  model. 

3.2.2  Characteristics  of  the  content 

Some  hypertext  systems  may  favor  an  organization  in  which  each  piece  of  content  is  treated  as 
a  small  card-sized  unit  while  others  favor  organizations  in  which  the  content  is  viewed  as  a  long 
continuous  scroll.  Such  considerations  are  outside  of  the  scope  of  the  r-model. 

3.2.3  Physical-level  descriptions  and  interchange  descriptions 

If  the  structure  of  the  implemented  hypertext  system  closely  parallels  that  of  the  r-model,  it  will 
certainly  be  necessary  to  define  a  storage  format  for  those  representations  that  are  specified  directly 
as  well  as  a  description  of  the  mappings  that  produce  the  others.  However,  the  specific  design  of 
such  storage  formats  is  outside  of  the  scope  of  the  r-model,  as  is  the  equally-important  design  of 
formats  designed  to  permit  interchange  between  hypertext  systems  and  installations. 

3.2.4  User  interfaces 

Certainly  to  the  reader  of  a  hypertext,  the  most  visible  component  of  the  system  is  its  user  interface. 
However,  the  user  interface  is  also  an  element  of  the  system  not  discussed  in  the  r-model.  We  note 
that  it  is  possible  to  associate  many  different  styles  of  user  interface  with  the  same  underlying 
hypertext  model. 

3.3    Intersection  with  existing  standards 

There  are  two  points  of  intersection  between  the  r-model  and  existing  standards.  The  first,  in  the 
abstract  component  level,  are  the  abstractions  used  to  define  the  abstract  content.  An  appropriate 
standard  to  consider  for  text,  for  example,  would  be  SGML  [IS086].  Similar  utility  could  be  made 
of  standards  to  define  graphical  material  as  well  as  other  content  objects.  It  may  be  necessary, 
however,  to  augment  these  standard  representations  with  additional  information  describing  the 
potential  interactions  defined  by  the  concrete-structure  and  button-structure  associations,  and  as 
reflected  in  the  concrete  content. 

The  other  point  of  intersection  with  proposed  standards  is  in  the  visible  hypertext  level.  Each 
visible  HT  segment  and  user  display  may  be  based  around  a  protocol  such  as  that  of  the  X- windows 
system  [SG86].  Other  defacto  interface  standards  such  as  SunTools,  OpenLook,  Viewpoint,  Motif, 
and  NextStep  are  also  applicable  at  this  point. 

4    Discussion  and  conclusions 

We  have  described  a  meta- model  of  hypertext,  which  we  call  the  r-model,  that  helps  to  organize  the 
portions  of  a  hypertext  model.  It  is  possible  that  the  hypertext  model's  design  will  also  correspond 


-91- 


to  the  divisions  established  in  the  r-model,  but  it  is  equally  permissible  that  the  relationships 
be  less-clearly  drawn  in  the  hypertext  model.  Furthermore,  the  implementation  of  the  hypertext 
system  may  also  correspond  directly  to  the  model  or  again  distinct  model  concepts  may  be  merged 
in  implementation. 

In  our  own  work  in  developing  the  Trellis  hypertext  model  and  prototype  implementations,  we 
have  tended  to  reflect  the  divisions  of  the  r-model  strongly  in  our  hypertext  model  and  also  to 
carry  these  divisions  on  into  our  implementation.  In  essence,  our  implementation  is  based  on  a 
collection  of  abstract  data  types,  where  the  data  types  correspond  to  the  representations  in  the 
r-model.  A  natural  consequence  of  this  retention  of  separation  has  been  that  it  is  easy  to  extend 
the  environment  in  which  the  implementation  resides — for  example  to  consider  designs  that  permit 
multiple  readers  to  be  active  in  the  hypertext  at  the  same  time  that  a  writer  is  modifying  it. 
Moreover  the  retention  of  separation  between  structure,  content,  and  context  permits  flexible  reuse 
of  the  hypertext's  structure  and  of  the  content  of  the  hypertext. 

While  we  believe  that  direct  application  of  the  r-model  has  benefits  in  guiding  the  implemen- 
tation of  a  hypertext  system,  we  also  believe  that  a  greater  understanding  of  a  hypertext  model 
can  be  gained  by  casting  it  into  the  form  of  the  r-model.  It  is  this  increased  understanding  that  we 
believe  is  of  primary  importance  outside  of  the  context  of  our  own  development. 

Acknowledgments 

<  We  would  like  to  thank  the  Hypertext  Standardization  Workshop  program  committee,  particularly 
Judi  Moline,  for  comments  that  helped  us  to  clarify  the  points  of  this  report.  We  also  would  like  to 
thank  the  participants  in  the  Workshop's  Hypertext  Reference  Model  working  group,  particularly 
John  Leggett,  for  discussions  that  helped  identify  the  similarities  and  differences  between  this  model 
and  the  others  that  have  been  proposed. 

References 

[FS89a]  Richard  Furuta  and  P.  David  Stotts.  Separating  hypertext  content  from  structure  in 
Trellis.  In  Proceedings  of  Hypertext  2,  June  1989.  University  of  York,  June  29th  and  30th, 
1989. 

[FS89b]  Richard  Furuta  and  P.  David  Stotts.  Programmable  browsing  semantics  in  Trellis.  In 
Hypertext  '89  Proceedings,  pages  27-42.  ACM,  New  York,  November  1989. 

[HS90]  Frank  Halasz  and  Mayer  Schwartz.  The  Dexter  hypertext  reference  model,  January  1990. 
These  proceedings. 

[IS086]  ISO.  Text  and  Office  Systems — Standard  Generalized  Markup  Language,  October  1986. 
Document  Number:  ISO  8879-1986(E). 

[LSK88]  John  Leggett,  John  L.  Schnase,  and  Charles  J.  Kacmar.  Working  definitions  of  hyper- 
text. Technical  Report  TAMU  88-020,  Department  of  Computer  Science,  Texas  A&M 
University,  October  1988. 

[SF89a]  P.  David  Stotts  and  Richard  Furuta.  Petri-net-based  hypertext:  Document  structure  with 
browsing  semantics.  ACM  Transactions  on  Information  Systems,  7(l):3-29,  January  1989. 


-92- 


[SF89b]  P.  David  Stotts  and  Richard  Furuta.  Temporal  hyperprogramming.  Technical  Report 
CS-TR-2349  and  UMIACS-TR-89-113,  University  of  Maryland  Department  of  Computer 
Science  and  Institute  for  Advanced  Computer  Studies,  November  1989. 

[SG86]  Robert  W.  Scheifier  and  Jim  Gettys.  The  X  Window  system.  ACM  Transactions  on 
Graphics,  5(2):79-109,  April  1986. 

[Sha80]  Alan  C.  Shaw.  A  model  for  document  preparation  systems.  Technical  Report  80-04-02, 
University  of  Washington,  Department  of  Computer  Science,  Seattle,  WA,  April  1980. 


-93- 


The  Dexter  Hypertext  Reference  Model* 


Frank  Halasz 


Mayer  Schwartz 


Xerox  PARC 


Tektronix  Labs 


3333  Coyote  Hill  Rd. 
Palo  Alto,  CA  94304 
halasz@xerox.com 


P.O.  Box  500,  MS  50-662 
Beaverton,  OR  97077 
mayers@tekchips.labs.tek.com 


December  7,  1989 

Submttied  io  the  NIST  Hypertexi  Standardizaiion  Workshop, 
Gaiihersburg,  MD,  January  16-18,  1990 


Abstract 


This  paper  presents  the  Dexter  hypertext  reference  model.  The 
Dexter  model  is  an  attempt  to  capture,  both  formally  and  informally, 
the  important  abstractions  found  in  a  wide  range  of  existing  and  future 
hypertext  systems.  The  goal  of  the  model  is  to  provide  a  principled 
basis  for  comparing  systems  as  well  as  for  developing  interchange  and 
interoperability  standards.  The  model  is  divided  into  three  layers. 
The  storage  layer  describes  the  network  of  nodes  and  links  that  is  the 
essence  of  hypertext.  The  runtime  layer  describes  mechanisms  support- 
ing the  user's  interaction  with  the  hypertext.  The  within-component 
layer  covers  the  content  and  structures  within  hypertext  nodes.  The 
focus  of  the  model  is  on  the  storage  layer  as  well  as  on  the  mechanisms 
of  anchoring  and  presentation  specification  that  form  the  interfaces 
between  the  storage  layer  and  the  within-component  and  runtime  lay- 
ers, respectively.  The  model  is  formalized  using  Z  [19],  a  specification 
language  based  on  set  theory.  The  paper  briefly  discusses  the  issues 
involved  in  comparing  the  characteristics  of  existing  systems  against 
the  model. 


*  AcknowledgeiTient:  The  model  described  in  this  paper  grew  out  a  series  of  workshops 
on  hypertext.  The  following  people  attended  these  workshops  and  were  instrumental  in 
the  development  of  the  model;  Rob  Akscyn,  Doug  Engelbart,  Steve  Feiner.  Frank  Ha- 
lasz, John  Leggett,  Don  McCracken,  Norm  Meyrowilz,  Tim  Oren,  Amy  Pearl,  Catherine 
Plaisant,  Mayer  Schwartz,  Randy  Trigg,  Jan  Walker,  and  Bill  Wieland.  The  workshops 
were  organized  by  Jan  Walker  and  John  Leggett. 


-95- 


What  do  hypertext^ystems  such  as  NoteCards  [10],  Neptune  [4],  KMS 
[1],  Intermedia  [23]  and  Augment  [6]  have  in  common?  How  do  they  differ? 
In  what  way  do  these  systems  differ  from  related  classes  of  systems  such 
as  multimedia  database  systems.  At  a  very  abstract  level,  each  of  these 
hypertext  systems  provides  its  users  with  the  ability  to  create,  manipulate, 
and/or  examine  a  network  of  information-containing  nodes  interconnected 
by  relational  links.  Yet  these  systems  differ  markedly  in  the  specific  data 
models  aiid  sets  of  functionality  that  they  provide  to  their  users.  Augment, 
Intermedia,  NoteCards,  and  Neptune,  for  example,  all  provide  their  users 
with  a  universe  of  arbitrary-length  documents.  KMS  and  HyperCard,  in 
contrast,  are  built  around  a  model  of  a  fixed-size  canvas  onto  which  items 
such  as  text  and  graphics  can  be  placed.  Given  these  two  radically  different 
designs,  is  there  anything  common  between  these  systems  in  their  notions 
of  hypertext  nodes? 

In  an  attempt  to  provide  a  principled  basis  for  answering  these  ques- 
tions, this  paper  presents  the  Dexter  hypertext  reference  model.  The  model 
provides  a  standard  hypertext  terminology  coupled  with  a  formal  model  of 
the  important  abstractions  commonly  found  in  a  wide  range  of  hypertext 
systems  Thus,  the  Dexter  model  serves  as  a  standard  against  which  to  com- 
pare and  contrast  the  characteristics  and  functionality  of  various  hypertext 
(and  non-hypertext)  systems.  The  Dexter  model  also  serves  as  a  principled 
basis  on  which  to  develop  standards  for  interoperability  and  interchange 
among  hypertext  systems. 

The  Dexter  reference  model  described  in  this  paper  was  initiated  as  the 
result  of  two  small  workshops  on  hypertext.  The  first  workshop  was  held  in 
October,  1988  at  the  Dexter  Inn  in  New  Hampshire.  Hence  the  name  of  the 
model.  The  workshops  had  representatives  from  many  of  the  major  existing 
hypertext  systems^.  A  large  part  of  the  discussion  at  these  workshops  was 
the  elicitation  of  the  abstractions  common  to  the  major  hypertext  systems. 
The  Dexter  model  is  an  attempt  to  capture,  fill-out,  and  formalize  the  results 
of  these  discussions. 

'The  term.s  hypertext  and  hypiermedia  are  often  differentiated,  with  hypertext  referring 
to  text-only  systems  and  hypermedia  refering  to  systems  that  support  multiple  media. 
This  distinction  is  not  made  in  the  present  paper;  the  term  hyf>ertext  is  used  generically 
to  refer  to  both  text-only  and  multimedia  systems. 

^Participants  in  the  two  workshops  are  listed  in  the  acknowledgements  on  the  first  page 
of  this  paper. 

Among  the  systems  that  were  discussed  at  the  workshops  were:  Augment,  Concor- 
dia/Document  Examiner,  IGD,  FRESS,  Intermedia,  HyperCard,  Hyperties,  KMS/ZOG, 
Neptune/HAM,  NoteCards,  the  Sun  Link  Service,  and  Textnet. 


-96- 


Another  important  focus  of  the  workshops  was  an  attempt  to  find  a 
common  terminology  for  the  hypertext  field.  This  turned  out  to  be  an 
extremely  difficult  task,  especially  so  in  the  absence  of  an  understanding  of 
the  common  (and  differing)  abstractions  among  the  various  systems.  The 
term  "node"  turned  out  to  be  especially  difficult  given  the  extreme  variation 
in  the  use  of  the  term  across  the  various  systems.  By  providing  a  well- 
defined  set  of  named  abstractions,  the  Dexter  model  provides  a  solution  to 
the  hypertext  terminology  problem.  It  does  so,  however,  at  some  cost.  In 
order  to  avoid  confusion,  the  model  does  not  use  contentious  terms  such  as 
"node",  prefering  neutral  terms  such  as  "component"  for  the  abstraction  in 
the  model. 

In  the  present  paper,  the  Dexter  model  is  formulated  in  Z  [19],  a  formal 
specification  language  based  on  typed  set  theory.  The  use  of  Z  provides  a 
rigorous  basis  for  defining  the  necessary  abstractions  and  for  discussing  their 
use  and  interrelationships.  Although  an  understanding  of  the  Z  language 
is  a  prerequisite  for  fully  understanding  the  details  of  the  Dexter  model  as 
described  in  this  paper,  the  paper  attempts  to  provide  a  complete  description 
of  the  model  in  the  prose  accompanying  the  formal  specification.  Readers 
unfamiliar  with  Z  should  be  able  to  gain  a  full,  if  not  precisely  detailed, 
understanding  of  the  model. 

This  paper  also  refers  in  passing  to  architectural  concepts  found  in 
a  number  of  existing  hypertext  systems  including  Augment  [6],  Concor- 
dia/Document  Examiner  [22],  HyperCard  [8],  Hyperties  [18],  IGD  [7],  In- 
termedia [23],  KMS  [1],  Neptune/HAM  [4],  NoteCards  [10],  the  Sun  Link 
Service  [17],  and  Textnet  [20].  The  reader  is  assumed  to  be  familiar  with 
the  general  characteristics  and  functionality  of  these  systems.  Appropriate 
background  material  on  these  systems  can  be  found  in  Conklin  [3]  and  in 
the  proceedings  of  the  Hypertext  87  [11]  and  Hypertext  89  [12]  conferences. 

This  paper  is  divided  in  4  main  sections.  The  first  section  provides  a 
brief  discursive  overview  of  the  entire  model.  The  second  section  describes 
the  storage  layer  of  the  model,  both  formally  and  informally.  The  third 
section  describes  the  runtime  layer  of  the  model  in  a  similar  manner.  The 
final  section  discusses  issues  involved  in  comparing  existing  systems  against 
the  model. 


-97- 


Focus  of  the 
Dexter  Model 


Figure  1:  Layers  of  the  Dexter  model. 

1    An  Overview  of  the  Model 

The  Dexter  model  divides  a  hypertext  system  into  three  layers,  the  run- 
time layer,  the  storage  layer  and  the  within-component  layer,  as  illustrated 
in  Figure  1.  The  main  focus  of  the  model  is  on  the  storage  layer,  which 
models  the  basic  node/link  network  structure  that  is  the  essence  of  hyper- 
text. The  storage  layer  describes  a  'database'  that  composed  of  a  hierar- 
chy of  data- containing  "components"  which  are  interconnected  by  relational 
"links".  Components  correspond  to  what  is  typically  thought  of  as  nodes  in 
a  hypertext  network:  cards  in  NoteCards  and  HyperCard,  frames  in  KMS, 
documents  in  Augment  and  Intermedia,  or  articles  in  Hyperties.  Compo- 
nents contain  the  chunks  of  text,  graphics,  images,  animations,  etc.  that 
form  the  basic  content  in  the  hypertext  network. 

The  storage  layer  focuses  on  the  mechanisms  by  which  the  components 
and  links  are  "glued  together"  to  form  hypertext  networks.  The  components 
are  treated  in  this  layer  as  generic  containers  of  data.  No  attempt  is  made 
to  model  any  structure  within  the  container.  Thus,  the  storage  layer  makes 
no  differentiation  between  text  components  and  graphics  components.  Nor 
does  it  provide  any  mechanisms  for  dealing  with  the  W2ll-defined  structure 
inherent  within  a  structured  document  (e.g.,  an  ODA  document)  compo- 


Runtime  Layer 

Presentation  of  the  tiypertext; 
user  interaction;  dynamics 


Storage  Layer 

a  'database'  containing  a 
network  of  nodes  and  links 


Within  Component  Layer 

the  content/structure  inside 
the  nodes 


-98- 


nent. 

In  contrast,  the  within-component  layer  of  the  model  is  specifically  con- 
cerned with  the  contents  and  structure  within  the  components  of  the  hyper- 
text network.  This  layer  is  purposefully  not  elaborated  within  the  Dexter 
model.  The  range  of  possible  content/structure  that  can  be  included  in  a 
component  is  open-ended.  Text,  graphics,  animations,  simulations,  images, 
and  many  more  types  of  data  have  been  used  as  components  in  existing 
hypertext  systems.  It  would  be  folly  to  attempt  a  generic  model  covering 
all  of  these  data  types.  Instead,  the  Dexter  model  treats  within-component 
structure  as  being  outside  of  the  hypertext  model  per  se.  It  is  assumed 
that  other  reference  models  designed  specifically  to  model  the  structure  of 
particular  applications,  documents,  or  data  types  (ODA,  IGES,  etc)  will  be 
used  in  conjunction  with  the  Dexter  model  to  capture  the  entirety  of  the 
hypertext,  including  the  with-component  content  and  structure. 

An  extremely  critical  piece  of  the  Dexter  model,  however,  is  the  inter- 
face between  the  hypertext  network  and  the  within-component  content  and 
structure.  The  hypertext  system  requires  a  mechanism  for  addressing  (refer- 
ing  to)  locations  or  items  within  the  content  of  an  individual  component.  In 
the  Dexter  model,  this  mechanism  is  know  as  anchoring.  The  anchoring 
mechanism  is  necessary,  for  example,  to  support  span-to-span  links  such 
as  are  found  in  Intermedia.  In  Intermedia,  the  components  are  complete 
structured  documents.  Links  are  possible  not  only  between  documents,  but 
between  spans  of  characters  within  one  document  and  spans  of  characters 
within  another  document.  Anchors  are  a  mechanism  that  provides  this 
functionality  while  maintaining  a  clean  separation  between  the  storage  and 
within-component  layers. 

The  storage  and  within-component  layers  treat  hypertext  as  an  essen- 
tially passive  data  structure.  Hypertext  systems,  however,  go  far  beyond 
this  in  the  sense  that  they  provide  tools  for  the  user  to  access,  view,  and 
manipulate  the  network  structure.  This  functionality  is  captured  by  the 
runtime  layer  of  the  model.  As  in  the  case  of  within-component  structure, 
the  range  of  possible  tcxjls  for  accessing,  viewing,  and  manipulating  a  hy- 
pertext networks  is  far  too  broad  and  too  diverse  to  allow  a  simple,  generic 
model.  Hence  the  Dexter  model  provides  only  a  bare-bones  model  of  the 
mechanism  for  presenting  a  hypertext  to  the  user  for  viewing  and  editing. 
This  presentation  mechanism  captures  the  essentials  of  the  dynamic,  inter- 
actional aspects  of  hypertext  systems,  but  it  does  not  attempt  to  cover  the 
details  of  user  interaction  with  the  hypertext. 

As  in  the  case  of  anchoring,  a  critical  aspect  of  the  Dexter  model  is  the 


-99- 


"View  as 


Presentation  spedfications 
on  link  access  path 


Figure  2:  Dlustration  of  the  need  for  presentation  specifications  on  the  access 
path  (i.e.,  Links)  as  well  as  on  the  components  themselves. 

interface  between  the  storage  layer  and  the  runtime  layer.  In  the  Dexter 
model  this  is  axrcomplished  using  the  notion  of  presentation  specifications. 
Presentation  specifications  axe  a  mechanism  by  which  information  about 
how  a  component/network  is  to  be  presented  to  the  user  can  be  encoded 
into  the  hypertext  network  at  the  storage  layer.  Thus,  the  way  in  which  a 
component  is  presented  to  the  user  can  be  a  function  not  only  of  the  specific 
hypertext  tool  that  is  doing  the  presentation  (i.e.,  the  specific  runtime  layer), 
but  can  also  be  a  property  of  the  component  itself  and/or  of  the  access  path 
(link)  taken  to  that  component. 

Figure  2  illustrates  the  importance  of  the  presentation  specifications 
mechanism.  In  this  figure,  there  is  an  animation  component  taken  from 
a  computer-based  training  hypertext.  This  animation  component  can  be 
accessed  from  two  other  components,  a  "teacher"  component  and  a  "stu- 
dent" component.  When  following  the  link  from  the  student  component, 
the  animation  should  be  brought  up  as  a  running  animation.  In  contast, 
when  coming  from  the  teacher  component,  the  animation  should  be  brought 
up  in  editing  mode  ready  to  be  altered.  In  order  to  separate  these  two  cases, 
the  runtime  layer  needs  to  access  presentation  information  encoded  into  the 
Links  in  the  network.  Presentation  specifications  are  a  generic  way  of  doing 
just  this.  Like  anchoring,  it  is  an  interface  that  allows  the  storage  layer  to 
communicate  in  generic  way  with  the  runtime  layer  without  violating  the 
separation  between  the  two  layers. 

Figure  3  attempts  to  give  a  flavor  of  the  various  layers  of  the  Dexter 
model  as  they  are  embedded  within  an  typical  hypertext  system.  The  fig- 


-100- 


Runtime  Layer  Storage  Layer  Within-Component 

Layer 

Figure  3:  A  depiction  of  the  three  layers  of  the  Dexter  model  as  embedded 
in  an  actual  hypertext  system. 

ure  depicts  a  3  node/1  link  hypertext  network.  The  storage  layer  contains 
four  entities:  the  three  components  (i.e.,  nodes)  and  the  link.  The  actual 
contents  (text  and  graphics)  for  the  components  are  located  to  the  right  of 
the  storage  layer  in  the  within-components  layer.  In  the  runtime  layer,  the 
single  graphics  component  is  being  presented  to  the  user.  The  link  emanat- 
ing from  this  node  is  marked  by  an  arrowhead  located  near  the  bottom  of 
the  node's  window  on  the  computer  screen. 

2  Simple  Storage  Layer  Model 
2.1    An  Overview  of  the  Storage  Layer 

The  storage  layer  describes  the  structure  of  a  hypertext  as  a  finite  set  of 
components  together  with  two  functions,  a  resolver  function  and  an  accessor 
function.  The  accessor  and  resolver  functions  are  jointly  responsible  for 
"retrieving"  components,  i.e.,  mapping  specifications  of  components  into 
the  components  themselves. 

The  fundamental  entity  .and  basic  unit  addressability  in  the  storage  layer 
is  the  component.  A  component  is  either  an  atom,  a  link,  or  a  composite 


-101- 


entity  made  up  from  other  components.  Atomic  components  are  primitive 
in  the  (storage  layer  of  the)  model.  Their  substructure  is  the  concern  of  the 
within-components  layer.  Atomic  components  are  what  is  typically  thought 
of  a  "node"  in  a  hypertext  system,  e.g.,  a  card  in  NoteCaxds,  a  frame  in 
KMS,  a  document  in  Intermedia,  a  statement  in  Augment.  Links  are  entities 
that  represent  relations  between  other  components.  They  are  basically  a 
sequence  of  2  or  more  "endpoint  specifications"  each  of  which  refers  to  (a 
part  of)  a  component  in  the  hypertext.  The  structure  of  links  will  be  detailed 
below.  Composite  components  are  constructed  out  of  other  components. 
The  composite  component  hierarchy  created  when  one  composite  component 
contains  another  composite  is  restricted  to  be  a  direct- acyclic  graph  (DAG), 
i.e.,  no  composite  may  contain  itself  either  directly  or  indirectly.  Composite 
components  are  relative  rare  in  the  current  generation  of  hypertext  systems. 
One  exception  is  the  Augment  system  where  a  document  is  a  tree-structured 
composition  of  atomic  components  called  statements. 

Every  component  has  a  globally  unique  identity  which  is  captured  by 
its  unique  identifier  (UID).  UIDs  are  primitive  in  the  model,  but  they  are 
assumed  to  be  uniquely  assigned  to  components  across  the  entire  universe  of 
discourse  (not  just  within  the  context  of  a  single  hypertext).  The  accessor 
function  of  the  hypertext  is  responsible  for  "accessing"  a  component  given 
its  UID,  i.e.,  for  mapping  a  UID  into  the  component  "assigned"  that  UID. 

UIDs  provide  a  guaranteed  mechanism  for  addressing  any  component 
in  a  hypertext.  But  the  use  of  UIDs  as  a  basic  addressing  mechanism  in 
hypertext  may  be  too  restrictive.  For  example,  it  is  possible  in  the  Augment 
system  to  create  a  link  to  "the  statement  containing  the  word  'pollywog'". 
The  statement  specified  by  this  link  may  not  exist  or  it  may  change  over 
time  as  documents  are  edited.  Therefore,  the  link  cannot  rely  on  a  specific 
statement  UID  to  address  the  target  statement.  Rather,  when  the  link  is 
followed,  the  specification  must  be  "resolved"  to  a  UID  (if  possible),  which 
then  can  be  used  to  access  the  correct  component. 

This  kind  of  indirect  addressing  is  supported  in  the  storage  layer  using 
component  specifications  together  with  the  resolver  function.  The  resolver 
function  is  responsible  for  "resolving"  a  component  specification  into  a  UID, 
which  can  then  be  fed  to  the  accessor  function  to  retrieve  the  specified  com- 
ponent. Note,  however,  that  the  resolver  function  is  only  a  partial  function. 
A  given  specification  may  not  be  resolvable  into  a  UID,  i.e.,  the  component 
being  specified  may  not  exist.  However,  it  is  the  case  that  for  every  com- 
ponent there  is  at  least  one  specification  that  will  resolve  to  the  UID  for 
that  component.  In  particular,  the  UID  itself  may  be  used  as  a  specifier,  in 


-102- 


which  case  the  resolver  function  is  the  identity  function. 

Implementing  span-to-span  links  (e.g.,  in  Intermedia)  requires  more  than 
simply  specifying  entire  components.  Span-to-span  linking  depends  on  a 
mechanism  for  specifying  substructure  within  components.  But  in  order 
to  preserve  the  boundary  between  the  hypertext  network  per  se  and  the 
content/structure  within  the  components,  this  mechanism  cannot  depend 
in  any  way  on  knowledge  about  the  interna!  structure  of  (atomic)  compo- 
nents. In  the  Dexter  model,  this  is  accomplished  by  an  indirect  addressing 
entity  called  an  anchor.  An  anchor  has  two  parts:  an  anchor  id  and  an 
anchor  value.  The  anchor  vaJue  is  an  arbitrary  value  that  specifies  some  lo- 
cation, region,  item,  or  substructure  within  a  component.  This  anchor  vaJue 
is  interpretable  only  by  the  applications  responsible  for  handling  the  con- 
tent/structure of  the  component.  It  is  primitive  and  unrestricted  from  the 
viewpoint  of  the  storage  layer.  The  anchor  id  is  an  identifier  which  uniquely 
identifies  its  anchor  within  the  scope  of  its  component.  Anchors  can  there- 
fore be  uniquely  identified  across  the  whole  universe  by  a  component  UID, 
anchor  id  pair. 

The  two  part  composition  of  anchor  is  designed  to  provide  a  fixed  point 
of  reference  for  use  by  the  storage  layer,  the  anchor  id,  combined  with  a 
variable  field  for  use  by  the  within-component  layer,  the  anchor  value.  As 
a  component  changes  over  time  (e.g.,  when  it  is  edited  within  the  runtime 
layer),  the  within-component  application  will  change  the  anchor  value  to 
reflect  changes  to  the  internal  structure  of  the  component  or  to  reflect  within 
component  movement  of  the  point,  region,  or  items  to  which  the  anchor 
is  conceptually  attached.  The  anchor  is,  however,  will  remain  constant, 
providing  a  fixed  referent  that  can  be  used  to  specify  a  given  structure 
within  a  component. 

The  mechanism  of  the  anchor  id  can  be  combined  with  the  component 
specification  mechanism  to  provide  a  v/ay  of  specifying  the  endpoints  of 
a  link.  In  the  model,  this  is  captured  by  an  entity  called  a  specifier  which 
consists  of  a  component  specification,  an  anchor  id,  and  two  additional  fields: 
a  direction  and  a  presentation  specification.  A  specifier  specifies  a  component 
and  an  anchor  'point'  within  a  component  that  can  serve  as  the  endpoint 
of  a  link.  The  direction  encodes  whether  the  specified  endpoint  is  to  be 
considered  a  source  of  a  link,  a  destination  of  a  link,  both  a  source  and  a 
destination,  or  neither  a  source  nor  a  destination.  (These  are  encoded  by 
direction  values  of  FROM,  TO,  BIDIRECT,  and  NONE,  respectively.)  The 
present  specification  is  a  primitive  value  that  forms  part  of  the  interface 
between  the  storage  layer  and  the  runtime  layer.  The  nature  and  use  of 


-103- 


C<»poslt«  f4112 


M.txibatos 
rr«MOt«tl«>_Sp«s  9BSSai 


ID 
t1 


MciihtK  nods 


and  00  on  and  on 


'resolves  to' 


9p»al  flats 
C«»Fceaiat_B|poei  #4112 
Ascaies_IS  f1 


'resoives  to'j, 


Figure  4:  A  depiction  of  overall  organization  of  the  storage  layer  including 
specifiers,  links,  and  anchors. 


present  specifications  will  be  discussed  in  conjunction  with  the  runtime  layer 
below. 

Returning  to  the  issue  of  link  components,  it  is  now  possible  to  describe 
their  structure  a  bit  more  precisely.  Ln  particular,  a  link  is  simply  a  sequence 
of  2  or  more  specifiers.  Note  that  this  provides  for  links  of  arbitrary  arity, 
despite  the  fact  that  binary  links  are  standard  in  existing  hypertext  systems. 
Directional  links,  cdso  standard  in  existing  systems,  are  handled  using  the 
direction  field  in  the  specifier. 

Figure  4  depicts  the  overall  organization  of  the  storage  layer  including 
specifiers,  links,  and  anchors.  The  figure  depicts  5  components  including  3 
atomic  components,  1  composite  component  (that  constructed  from  two  of 
the  atomic  components  plus  some  text),  and  1  link  component  that  repre- 
sents a  connection  from  the  anchor  (i.e.,  span)  within  an  atomic  component 
(#3346)  to  the  anchor  (span)  in  the  composite  component  (#4112). 

In  the  foregoing  discussion,  components  were  described  as  being  either 
a  atom,  a  link,  or  a  composition  of  other  components.  In  actuality,  this 
describes  what  the  model  calls  a  base  component.  In  contrast,  components 
in  the  model  are  complex  entities  that  contain  a  base  component  together 
with  some  associated  component  information.  The  component  information 


-104- 


describes  the  properties  of  the  component  other  than  its  'content'.  Specifi- 
cally, the  component  information  contains  a  sequence  of  anchors  that  index 
into  the  component,  a  present  specification  that  contains  information  for  the 
runtime  layer  about  how  the  component  should  be  presented  to  the  user, 
and  a  set  of  arbitrary  attribute/value  pairs.  The  attribute/value  pairs  can 
be  used  to  attach  any  arbitrary  property  (and  its  vaJue)  to  a  component.  For 
example,  keywords  can  be  attached  to  a  component  using  mutiple  'keyword' 
attributes.  Similarly,  a  component  type  system  can  be  implemented  in  the 
model  by  adding  to  each  component  a  'type'  attribute  with  an  appropriate 
type  specification  as  its  value. 

In  addition  to  a  data  model,  the  storage  layer  defines  a  small  set  of  op- 
erations that  can  be  used  to  access  and/or  modify  a  hypertext.  All  of  these 
operations  are  defined  in  such  a  way  a^  to  maintain  the  invariants  of  the 
hypertext,  e.g.,  the  fact  that  the  composition  hierarchy  of  components/sub- 
components is  acyclic.  The  operations  defined  in  the  model  include  adding 
a  component  (atomic,  link  or  composite)  to  a  hypertext,  deleting  a  compo- 
nent from  'he  hypertext,  and  modifying  the  contents  or  ancilliary  informa- 
tion (e.g.,  anchors  or  attributes)  of  a  component.  There  are  also  operatons 
for  retrieving  a  component  given  its  UID  or  any  specifier  that  can  be  re- 
solved to  its  UID.  Finally,  there  is  one  operation  needed  for  determining  the 
interconnectivity  of  the  network  structure.  This  operation,  linksToAnchor, 
returns  the  set  of  links  that  refer  to  an  anchor  when  given  the  anchor  and 
its  containing  component. 

2.2    Formalization  of  the  Storage  Layer 

As  described  above,  we  envision  a  hypertext  system  consisting  of  a  set  of 
components,  each  of  which  has  a  UID  from  the  given  set  UID. 

[UID] 

Retrieving  a  component  involves  finding  its  UID  and  then  using  that 
UID  to  get  hold  of  the  actual  component;  this  is  accomplished  by  means 
of  an  accessor  function  which  returns  a  component  given  its  UID.  UIDs  are 
normally  not  meant  to  be  visible  to  clients  of  a  hypertext  system.  Given 
a  component  specification,  it  may  be  possible  to  find  the  UID  to  which 
the  component  specification  refers,  by  means  of  a  resolver  function.  Com- 
ponent specifications  arise  from  the  given  set  COMPONENT-SPEC.  We 
also  have  a  description  for  the  visual  presentation  (present  spec)  of  a  com- 
ponent, which  as  part  of  a  component  is  used  in  the  run-time  layer  but 


-105- 


not  in  the  storage  layer;  these  visual  descriptions  come  from  the  given  set 
PRESENT^SPEC. 

[COMPONENT^PEC,  PRESENT JSPEC] 

Links  are  an  important  kind  of  component  and  are  supported  in  every 
hypertext  system.  Direction «ility  is  sometimes  important  for  links,  while  at 
other  times  it  immaterial.  We  introduce  DIRECTION  as  a  free  type  to 
model  respectively  the  end  of  a  link  as  a  source,  as  a  destination,  as  both  a 
source  and  destination,  or  as  neither. 

DIRECTION  ::=  FROM  \  TO  \  BYDIRECT  \  NONE 

The  schema  type  SPECIFIER  essentially  takes  the  form  of  the  descrip- 
tion of  one  end  of  a  "link."  This  description  is  sometimes  sufficient  to 
determine  the  UID  of  the  component  at  one  end  of  a  link.  As  described  in 
the  overview,  anchoring  plays  an  important  part  in  the  model.  Anchors  are 
identified  by  means  of  a  unique  (to  a  component)  anchor  id  from  the  given  set 
ANCHOR-ID.  Anchor  values  come  from  the  given  set  ANCHOR-VALUE. 
Anchors  are  then  just  pairs  of  anchor  id  and  associated  anchor  value. 

[ANCHOR-ID ,  A  NCHOR-  VA  L  UE] 

ANCHOR  ==  ANCHOR-ID  x  ANCHOR-VALUE 

A  value  of  type  SPECIFIER  describes  a  single  end  of  a  link.  We  include 
the  variable  presentSpec  in  the  SPECIFIER  schema  so  we  can  model  differ- 
ent ways  of  visually  showing  links  as  we  follow  them  (based  on  the  specifier 
used),  as  illustrated  in  the  example  shown  in  Figure  2. 

SPECIFIER  

componentSpec  :  COMPONENT-SPEC 
anchorSpec  :  ANCHOR-ID 
presentSpec  :  PRESENTSPEC 
direction  :  DIRECTION 


Links  must  include  at  least  two  specifiers.  What  appear  to  be  one-way 
links,  such  as  HyperCard  buttons,  can  be  modeled  as  two-way  links  with  the 
button  end  having  a  DIRECTION  with  value  NONE  and  the  other  end 
having  a  DIRECTION  with  value  TO.  The  two  specifiers  link  constraint 
simplifies  the  hypertext  model.  On  the  other  hand  there  is  no  reason  not 


-106- 


to  have  multi-way  links,  and  so  the  model  accomodates  them.  In  the  most 
general  model,  duplicate  specifiers  are  allowed.  The  only  constraint  is  that 
at  least  one  specifier  have  a  direction  of  TO. 

LINK  

specifiers  :  seq  SPECIFIER 

specifiers  >  2 
3  5  :  ran  specifiers  •  s. direction  =  TO 


A  base  component  (a  generalization  of  the  traditional  "node"  or  "link") 
of  a  hypertext  can  either  be 

•  an  atomic  element  which  is  modeled  by  the  given  type  ATOM, 

[ATOM] 

models  a  "node"  of  a  typical  hypertext  system  but  with  the  internal 
detail  omitted. 

•  a  link  which  is  modeled  by  the  LINK  schema  given  above,  or 

•  a  composite  which  can  be  described  recursively  as  a  sequence  of  base 
components. 

Components  can  have  ancillary  information  associated  with  them,  such 
as  at  tribute /value  pairs,  anchors,  or  presentation  information.  Most  hyper- 
text systems  allow  for  attributes  of  components.  These  attributes  can  be 
thought  of  as  attribute/value  pairs  which  can  be  modeled  as  a  partial  func- 
tion mapping  attributes  to  values.  We  thus  introduce  two  additional  given 
sets,  one  for  the  set  of  attribute  names  and  the  other  for  the  set  of  possible 
values: 

[ATTRIBUTE,  VALUE] 

The  additional  information  associated  with  a  base  component,  which  was 
mentioned  above,  can  be  captured  in  the  following  schema.  We  include  the 
invariant  that  anchor  ids  are  unique  within  a  given  component,  i.e.,  the 
number  of  anchors  within  a  component  is  equal  to  the  size  of  the  set  of 
(different)  anchors  within  the  component. 


-107- 


COMP^NFO  

attributes  :  ATTRIBUTE  VALUE 
anchors  :  seq  ANCHOR 
presentSpec  :  PRESENTJSPEC 

j^anchors  =  #(j^rsf  ^ran  anchors^) 


Note  that  a  presentSpec  always  has  some  value.  We  introduce  the  function 
minlnfo  which  returns  an  instance  of  this  schema  with  "minimaJ  informa- 
tion," that  is,  no  attributes,  no  anchors  and  a  presentSpec  which  is  given  as 
an  argument. 

minlnfo  :  PRESENTSPEC  -  COMP^NFO 

Vp5  :  PRESENTSPEC  • 

minInfo{ps)  =  (ji  info  :  COMP-INFO  \ 
info  .attributes  =  0  A 
info. anchors  =  ()  A 
info. presentSpec  =  ps) 

We  use  the  recursive  type,  BASE-COMPONENT,  to  describe  the  btise 
components  of  a  hypertext  system. 

BASE-COMPONENT  atom{{ATOM)) 

I  link{{LINK)) 

I    composite ((seq  BASE-COMPONENT)) 

Finally,  the  schema  COMPONENT  represents  a  base  component  along  with 
its  associated  information. 

COMPONENT  

compBase  :  BASE-COMPONENT 
camp  Info  :  COMP-INFO 


The  functions  defined  in  the  remainder  of  this  section  are  there  just 
to  make  the  specification  of  the  model  easier  to  read  and  understand  — 
they  are  not  meant  to  have  any  particular  significance  in  their  own  right. 
The  following  function  builds  a  component  given  its  base  component  and 
associated  information. 


-108- 


component  :  BASE^COMPONENT  x  COMP^INFO 
COMPONENT 


component  =  {Xb:  BASE.COMPONENT;  i  :  COMP^NFO  • 
{y.  c  :  COMPONENT  \ 
c.compBase  =  b  A 
c.complnfo  =  t)) 

The  following  two  functions  extract  respectively  the  base  coniponent  and 
associated  information  of  a  component. 

6056  :  COMPONENT  BASE.COMPONENT 
info  :  COMPONENT  COMP^NFO 

Vc  :  COMPONENT  • 

hase{c)  =  C.compBase  A 
info{c)  =  c.complnfo 

We  introduce  three  predicates  (prefix  relations)  which  are  respectively 
true  iff  a  component  is  an  atom,  a  link,  or  a  composite. 

is  Atom  _  :  P  COMPONENT 
isLink_  :  P  COMPONENT 
isComposite_:  P  COMPONENT 

Vc  :  COMPONENT  • 

isAtomc  O  base(c)  €  vdniatom  A 
isLinkc      base{c)  €  ran  link  A 
isCompositec      base{c)  €  ran  composite 

We  also  define  a  "type"  consistency  relationship  between  components  — 
that  is,  two  components  are  "type  consistent"  is  they  are  both  atoms,  both 
links,  or  both  composites. 

_typeConsistent„:  COMPONENT  ^  COMPONENT 

Vci,C2  :  COMPONENT  • 
Ci  typeConsistent  C2  <^ 

(is  Atom  c\  A  is  Atom  C2)  V 
(isLink  Cj  A  isLink  cj)  V 
(isComposite  ci  A  isComposite  C2) 

Because  link  components  are  referred  to  quite  frequently  in  what  follows, 
we  introduce  the  schema  LinkComp  so  we  can  define  variables  of  that  type. 


-109- 


LinkComp  „„  

COMPONENT 

compBase  G  ran  link 


We  also  introduce  some  helpful  functions  to  extract  the  various  parts 
that  make  up  a  base  component  type.  The  first  two  functions  are  only 
defined  for  link  components  and  return  respectively  the  set  of  component 
specs  for  the  link  and  the  set  of  anchor  ids  for  the  link. 

componentSpecs  :  LinkComp     F  COMPONENT JSPEC 
anchor  Specs  :  LinkComp  -++  F  ANCHOR— ID 

V  c  :  LinkComp  « 

componentSpecs{c)  =  {cs  :  COMPONENT^PEC  | 
3  5  :  i^,X).{link'^ {base{c))). specifiers  » 
cs  —  s.cornponentSpec]  A 
anchorSpecs{c)  =  {as  :  ANCHOR J[D  \ 
•   '  3  s  :  Tdin{link'^{base{c))). specifiers  9 

as  —  s  .anchorSpec] 

The  next  two  functions  are  defined  for  any  component  and  return  respec- 
tively its  attributes  and  its  anchors. 

attributes  :  COMPONENT  -  {ATTRIBUTE  ^  VALUE) 
anchors  :  COMPONENT      F  ANCHOR 

V  c : COMPONENT  • 

attribuc€s{c)  —  {info(c)). attributes  A 
anchors{c)  ~  T?Ln{info(c)}. anchors 

Finally,  we  introduce  a  function  which  given  a  component  returns  a 
component  just  like  the  given  one  except  that  the  attributes  function  is 
(possibly)  overwritten  with  a  new  value  for  a  given  attribute. 


-110- 


modify  Attribute  :  COMPONENT  x  ATTRIBUTE  x  VALUE 

COMPONENT 


modifyAtthbute  =  (A  c  :  COMPONENT;  a  :  ATTRIBUTE; 

V  :  VALUE  • 
(/i  c'  :  COMPONENT  |  3  »,  i'  :  COMPLIN FO  \ 
i  ~  info{c)  • 
i' .attributes  =  i. attributes  ®  {a    »•  u}  A 
i'. anchors  =  i. anchors  A 
i' .presentSpec  =  i.presentSpec  A 
c'  =  compon€nii;(6a5€(c),  ?'))) 

Components  can  have  sub-components  and  the  same  component  may  be 
a  sub-component  to  more  than  one  component.  This  relationship  will  be 
denoted  by  _subcomp_  and  is  defined  below. 

_subcomp_:  COMPONENT  ^  COMPONENT 

Vci,C2  :  COMPONENT  • 
Ci  subcomp  Cj  O 

bas€{ci)  G  Ta.n{composite^(bas€(c2))) 

A  hypertext  system,  modeled  by  the  schema  PROTO-HYPERTEXT, 
has  three  parts.  (1)  The  set  of  components  represents  the  traditional  "nodes" 
and  "links"  of  a  hypertext  system.  (2)  A  partial  function  termed  the  resolver 
returns  the  DID  for  a  given  component  specifier.  Note  that  more  than  one 
specifier  may  return  the  same  UID.  (3)  To  actually  get  hold  of  a  component, 
we  introduce  an  accessor  function  which  given  a  UID  returns  a  component. 
Note  that  this  function  while  partial,  is  invertible. 

PR  O  TO^  YPER  TEX  T  

components  :  F  COMPONENT 
resolver  :  COMPONENT^PEC  UID 
accessor  :  UID  COMPONENT 


To  identify  those  links  resolving  to  a  given  component,  we  introduce  the 
function  linksTo  which,  given  a  hypertext  system  and  the  UID  of  a  compo- 
nent in  the  system,  returns  the  UIDs  of  links  resolving  to  that  component. 


-Ill- 


linksTo  :  PROTO-HYPERTEXT  x  UID      F  UID 


linksTo  =  iXH  :  PROTO.HYPERTEXT;  u  :  UID  •  {uid  :  UID  \ 
{3comp  :  LinkComp  |  comp  6  H .components  * 
uid  =  H .accessor" (comp)  A 
{3  s  •  COMPONENT ^PEC  \ 
s  €  componentSpecs{comp)  * 
u  =  H  .r€solv€r{s)))}) 

There  are  four  constraints  which  must  be  satisfied  by  an  instance  of  the 
schema  PROTOJYPERTEXT  before  we  can  caU  it  a  HYPERTEXT. 

•  The  accessor  function  must  yield  a  value  for  every  component.  Be- 
cause this  function  is  invertible,  every  component  must  then  have  a 
UID. 

•  The  resolver  function  must  be  able  produce  all  possible  valid  UIDs. 

•  There  are  no  cycles  in  the  component-subcomponent  relationship,  that 
is  no  component  may  be  a  subcomponent  (directly  or  transitively)  of 
itself. 

•  The  anchor  ids  of  a  component  must  be  the  same  as  the  anchor  ids  of 
the  component  specifiers  of  the  links  resolving  to  the  component. 


H  YPERTEX  T  .  . 

PR  O  TOJfl  YPER  TEX  T 

Vc  :  components  o  c  €  ran  accessor 
ran  resolver  =  dom  accessor 
Vc  :  components*  (c,c)  ^  (_subcomp_)* 
V  c  :  components  •  3  lids  :  F  UID  | 

lids  =  linksTo{ePROTOJYPERTEXT,  accessor-- {c))  • 

first  ^anchors{c))  = 

\J{{anchor Specs  o  accessor)^ltdsl) 


2.3    Adding  New  Components 

In  this  section  the  model  adding  a  new  component  to  a  hypertext.  The 
last  function  defined  in  this  section,  Create Nexv Component,  is  the  function 
actually  called  from  the  run-time  layer  and  is  also  part  of  the  external  view 


-112- 


of  the  model.  (See  the  section  on  conformance  with  the  reference  model  for 
more  about  this  external  view.) 

Adding  a  new  component  to  the  hypertext  is  given  by  the  following 
function.  It  ensures  that  the  range  of  the  accessor  function  is  extended  to 
include  the  new  component.  The  resolver  function  is  also  extended  so  that 
there  is  at  least  one  specifier  for  the  new  component's  corresponding  UID. 

create  Component  :  HYPERTEXT  x  COMPONENT 

HYPERTEXT 


^H  :  HYPERTEXT]  c  :  COMPONENT  • 
3  H'  :  HYPERTEXT  \ 

H' .components  =  H .components  U  {c}  A 
(3j  uid  :  UID  • 

(3  componentSpec  :  COMPONENT-SPEC  • 
H' .accessor  =  H .accessor  U  {uid  y-*  c}  A 
H' .resolver  =  H. resolver  U 

{componentSpec  >-*  nid}))  • 
createComponent{H ,  c)  —  H' 

The  functions  for  creating  a  new  node,  link,  and  composite  respectively 
are  given  below.  They  use  the  function  createComponent  described  above. 

createAtomicComponent  :  HYPERTEXT  x  ATOM 

X  PRESENT-SPEC  -  HYPERTEXT  x  COMPONENT 


Vi7  :  HYPERTEXT]  a  :  ATOM;  ps  :  PRESENT-SPEC  • 

3  c  :  COMPONENT  \  c  —  component{atom{a).,  minInfo{ps))  • 
create AtomicC omponent{H ,  a,  ps)  = 
{createComponent{H ,  c),  c) 

In  creating  a  link,  we  must  ensure  that  all  of  its  component  specifiers  re- 
solve to  existing  components.  To  test  for  such  consistency  among  links  we 
introduce  the  following  link  consistency  predicate  as  a  prefix  relation. 


-113- 


linkConsistent.  :  P  HYPERTEXT 


^  H  :  HYPERTEXT  • 
linkConsistent  H  ^ 

(yi  :  LINK;  s  :  SPECIFIER  \ 

(3  cl  :  LinkComp  \  cl  €  H .components  • 

/  =  link^{bas€(cl)))  A 
5  €  ran  I. specifiers  • 

(3  c  :  COMPONENT  \  c  e  H .components  • 

{H .accessor  o  H .resolv€r){s.componentSpec)  =  c)) 

Creating  a  new  link  component  is  then  given  by  the  following  function. 

createLinkComponent  :  HYPERTEXT  x  LINK  x  PRESENT^PEC 
HYPERTEXT  x  COMPONENT 


:  HYPERTEXT;  I  :  LINK;  ps  :  PRESENT^PEC  • 
3  ^'  :  HYPERTEXT;  c  :  COMPONENT  \ 
c  —  compon€nt(link{l).,minInfo{ps))  A 
H'  =  create Compon€nt{ H ,c)  A 
create LinkComponent{H I,  ps)  =  {H',c)  • 
linkConsistent  H' 

In  creating  a  composite  we  must  ensure  that  any  subcomponents  of  the  new 
composite  are  already  in  the  hypertext. 

create  Composite  Component  : 

HYPERTEXT  x  seq  BASE-COMPONENT 

xPRESENT-SPEC  -  HYPERTEXT  x  COMPONENT 


:  HYPERTEXT;  s  :  seq  BASE.COMPONENT; 

ps  :  PRESENT^PEC  • 
3  newComp  :  COMPONENT  \ 

newComp  =  component{composite{s) ,  minInfo{ps))  • 
createCompositeComponent{H ,  s,ps)  = 

{createComponent{H ,  newComp),  newComp)  A 
(Vc  :  COMPONENT  |  base{  c)  G  ran  5  • 
c  €  H .components) 

We  package  creating  a  new  component  with  the  following  function.  This 
is  the  function  which  will  ultimately  be  invoked  from  the  run- time  layer. 


-114- 


Create NewComponent  :  HYPERTEXT  x  BASE.COMPONENT 
xPRESENT_SPEC     HYPERTEXT  x  COMPONENT 


V/f  :  HYPERTEXT;  be  :  BASE.COMPONENT; 
ps  :  PRESENTJSPEC  • 
((3  a  :  ATOM  •  be  =  atom{a)) 

Create Ne wComponent(  H ,  be,  ps)  = 

createAtomicComponent(H ,  atom'' {be), ps))  A 
((3  /  :  LINK  •  be  =  link{l))  =^ 

Create NewComponent( H ,  bc,ps)  = 

createLinkComponent{H ,  link'" (be) ,  ps))  A 
((3  s  :  seq  BASE^COMPONENT  •  be  =  compositei s))  =^ 
Create NewComponent{  H ,  be,  ps)  — 

ereateCompositeComponent{H ,  composite'" {be) ,  ps)) 

2.4  Deleting  A  Component 

In  deleting  a  component  we  must  ensure  that  we  remove  any  links  whose 
specifiers  resolves  to  that  component. 

DeleteComponent  :  HYPERTEXT  x  UID  ^  HYPERTEXT 

DeleteComponent  =  {X  H  :  HYPERTEXT;  nid  :  UID  • 
{fi  H'  :  HYPERTEXT  \  3  uids  :  f  UID  \ 
uids  =  {uid}  U  linksTo{H ,uid)  • 

H' .components  =  H .components  \  H .accessor\uids)  A 
H' .accessor  =  uids     H .accessor  A 
H' .resolver  =  H .resolver  ^  uids)) 

2.5  Modifying  Components 

In  modifying  a  component  we  require  that  its  associated  information  remain 
unchanged,  that  its  type  (atom,  link,  or  composite)  remain  unchanged,  and 
that  the  resulting  hypertext  remains  link  consistent. 


-115- 


ModifyComponent  :  HYPERTEXT  x  UID  x  COMPONENT 

^  HYPERTEXT 


Viy  :  HYPERTEXT]  uid  :  WZ);  c'  :  COMPONENT  • 
3c:  COMPONENT;  H'  :  HYPERTEXT  \ 
c  -  H .accessor{uid)  A 

H' .components  —  H .components  \  {c)  U  {c'}  A 
H' .accessor  =  H .accessor  ^  {uid    ^  c'}  A 
H' .resolver  =  H .re solver  A 
m/o(c')  =  in/o(c)  A 
c  typeConsistent  c'  A 
linkConsistent  ^'  • 
ModifyComponent{H  ,uid,c)  =  H' 

2.6  Retrieving  A  Component 

To  retrieve  a  component,  given  its  UID,  means  just  to  have  the  returned 
value  of  the  accessor  function. 

getComponent  :  HYPERTEXT  x  UID  ^  COMPONENT 

^H  :  HYPERTEXT;  uid  :  WZ)  • 

getComponent{ H ,  uid)  =  H .accessor [uid) 

Given  a  UID  which  happens  to  represent  a  linii,  there  exist  operations 
which  return  either  a  source  or  destination  specifier  for  that  component. 

2.7  Attributes 

We  introduce  functions  to  both  get  and  set  the  value  of  a  given  attribute  (if 
it  exists)  for  a  given  component. 

AttributeValue  :  HYPERTEXT  x  UID  x  ATTRIBUTE  ^  VALUE 

^H  :  HYPERTEXT;  uid  :  UID;  a  :  ATTRIBUTE  • 
(3  c:  COMPONENT  |  c  =  H .accessor{uid)  • 

Attribute Value{H ,  uid,  a)  =  attributes{c){a)) 


-116- 


SetAttributeValue  :  HYPERTEXT  x  UID  x  ATTRIBUTE  x  VALUE 

HYPERTEXT 


SetAttributeValue  = 

{XH  :  HYPERTEXT;  uid  :  UID;  a  :  ATTRIBUTE; 

V  :  VALUE  • 
(/i  ^'  :  HYPERTEXT  |  3  c,  c' :  COMPONENT  • 
c  =  H .accessor {uid)  A 
c'  =  modify Attribute{c,  a,  v)  A 
H'. components  —  H .components  \  {c}  U  {c'}  A 
H' .accessor  =  H .accessor  Q  {uid      c'}  A 
H'  .resolver  =  H  .resolver)) 

There  is  aJso  a  function  which  returns  the  set  of  all  component  attributes. 

AllAttHbutes  :  HYPERTEXT  ->  F  ATTRIBUTE 

^H  :  HYPERTEXT  • 

AllAttributes{H)  =  {a  :  ATTRIBUTE  \3c:  COMPONENT  • 
a  €  dom(attributes{c))} 

2.8  Anchors 

It  is  sometimes  useful  to  know  the  link  components  which  are  associated 
with  a  particular  anchor.  The  function  LinksToAnchor  returns  the  set  of 
link  component  uids  associated  with  a  particular  anchor  id  for  a  particular 
component  id, 

LinksToAnchor  :  HYPERTEXT  x  UID  x  ANCHORED  -  F  UID 

LinksToAnchor  = 

(A^  :  HYPERTEXT;  u  :  UID;  aid  :  ANCHORED  • 
{lid  :  UID\3  lids  :  f  UID  \ 

lids  =  linksTo(H ,  u)  A  lid  €  lids  • 

aid  6  {anchorSpecs  0  H .accessor)(lid)}) 


-117- 


3    Simple  Runtime  Layer  Model 


3.1    An  Overview  of  the  Runtime  Layer 

The  fundamental  concept  iu  the  runtime  layer  is  the  instantiation  of  a  com- 
ponent. An  instantiation  is  a  presentation  of  the  component  to  the  user. 
Operationally,  an  instantiation  should  be  thought  of  as  a  kind  of  runtime 
cache  for  the  component.  A  'copy'  of  the  component  is  cached  in  the  in- 
stantiation, the  user  views  and/or  edits  this  instantiation,  and  the  altered 
cache  is  then  'written'  back  into  the  storage  layer.  Note  that  there  can  be 
more  than  one  simultaneous  instantiation  for  any  given  component.  Each 
instantiation  is  assigned  a  unique  (within  session,  see  below)  instantiation 
identifier  (IID). 

Instantiation  of  a  component  also  results  in  instantiation  of  its  anchors. 
An  instantiated  anchor  is  known  as  a  link  marker.  This  terminology  is  con- 
gruent with  that  used  in  Intermedia,  where  the  term  "anchor"  refers  to  an 
attachment  point  or  region  and  the  term  "link  marker" refers  to  the  visible 
manifestation  of  that  anchor  in  a  displayed  document.  In  order  to  accomo- 
date the  link  marker  notion  within  the  model,  an  instantiation  is  actually 
a  complex  entity  containing  a  feci^e  instantiation  together  with  a  sequence 
of  link  markers  and  a  function  mapping  link  markers  to  the  anchors  they 
instantiate.  A  base  instantiation  is  a  primitive  in  the  model  that  represents 
some  sort  of  presentation  of  the  component  to  the  user. 

At  any  given  moment,  the  user  of  a  hypertext  can  be  viewing  and/or  edit- 
ing any  number  of  component  instantiations.  The  runtime  layer  includes  an 
entity  called  a  session  which  serves  to  keep  track  of  the  moment-by-moment 
mapping  between  components  and  their  instantiations.  Specifically,  when  a 
user  wants  to  access  a  hypertext,  he  or  she  opens  a  session  on  that  hyper- 
text. The  user  can  then  create  instantiations  of  components  in  the  hypertext 
(an  action  known  as  "presenting"  the  component).  The  user  can  edit  these 
instantiations,  can  modify  the  component  based  on  the  accumulated  edits 
to  the  instantiation  (an  action  known  as  "realizing"  the  edits),  and  finally 
can  destroy  the  instantiation  (an  action  known  as  "unpresenting"  a  compo- 
nent). When  the  user  is  finished  interacting  with  the  hypertext,  the  session 
is  closed. 

In  the  model,  the  session  entity  contains  the  hypertext  being  accessed, 
a  mapping  from  the  IIDs  of  the  session's  current  instantiations  to  their 
corresponding  components  in  the  hypertext,  a  history,  a  runtime  resolver 
function,  an  instantiator  function,  and  a  realizer  function.   At  any  given 


-118- 


moment,  the  history  is  a  sequence  of  all  operations  carried  since  the  last 
open  session  operation.  In  the  present  version  of  the  model,  this  history  is 
used  only  in  defining  the  notion  of  a  read-only  session.  It  is  intended  to 
be  available,  however,  to  any  operation  that  needs  to  be  conditionalized  on 
preceeding  operations. 

The  session's  runtime  resolver  function  is  the  runtime  version  of  the  stor- 
age layer's  resolver  function.  Like  the  resolver,  it  maps  specifiers  into  com- 
ponent UIDs,  The  runtime  resolver,  however,  can  use  information  about 
the  current  session,  including  its  history,  in  the  resolution  process.  The 
storage  resolver  layer  has  no  access  to  such  runtime  information.  For  exam- 
ple, a  specifier  may  refer  to  "the  most  recently  accessed  component  named 
'xyzzy' The  runtime  resolver  is  responsible  for  mapping  this  specifier  into 
the  UID  matching  this  specification.  The  storage  layer  resolver  would  not 
be  able  handle  this  specification.  The  runtime  resolver  is  restricted  to  be  a 
superset  of  the  storage  layer  resolver  function;  any  specifier  that  the  storage 
layer  resolver  can  resolve  to  a  UID  must  be  resolved  to  the  same  UID  by  the 
runtime  resolver. 

At  the  heart  of  the  runtime  model  is  the  session's  instantiator  function. 
Input  to  the  instantiator  consists  of  a  component  (UID)  and  a  presentation 
specification.  The  instantiator  returns  an  instantiation  of  the  component  as 
part  of  the  session.  The  presentation  specification  is  primitive  in  the  model, 
but  is  intended  to  contain  information  specifying  how  the  component  being 
instantiated  is  to  be  "presented"  by  the  system  during  this  instantiation. 
Note  that  the  component  itself  has  a  presentation  specification  from  the 
storage  layer  of  the  model.  This  presentation  specification  is  meant  to  con- 
tain information  about  the  component's  own  notion  of  how  it  should  be 
presented.  It  is  the  responsibility  of  the  instantiator  function  to  adjudicate 
(by  selection  or  combination  or  otherwise)  among  the  presentation  specifi- 
cation passed  to  the  instantiator  and  the  presentation  specification  attached 
to  the  component  being  instantiated.  The  model  in  its  current  form  does 
not  maJie  this  adjudication  explicit. 

The  instantiator  function  is  the  core  of  a  the  present  component  op- 
eration. Present  component  takes  a  component  specifier  (together  with  a 
session  and  a  presentation  specification)  and  calls  the  instantiator  using  the 
component  UID  derived  from  resolving  the  specifier.  Present  component 
in  turn  is  the  core  of  the  follow  link  operation.  Follow  link  takes  (the  IID 
of)  an  instantiation  together  with  a  link  marker  contained  within  that  in- 
stantiation. It  then  presents  the  component(s)  that  are  at  the  destination 
endpoints  (i.e.,  endpoints  whose  specifier  has  direction  of  TO)  of  all  link(s) 


-119- 


that  have  as  an  endpoint  the  anchor  represented  by  the  given  link  marker. 
In  the  case  where  all  links  are  binary,  this  is  equivalent  to  following  a  link 
from  the  link  marker  for  its  source.  The  result  of  following  the  link  is  a 
presentation  of  its  destination  component  and  anchor. 

The  instantiator  function  also  has  an  "inverse"  function  called  the  real- 
izer  function  which  takes  an  instantiation  and  returns  a  (new)  component 
that  "reflects"  the  current  state  of  the  instantiation  (i.e.,  including  recent 
edits  to  the  instantiation).  This  is  the  basic  mechanism  for  "writing  back 
the  cache"  after  an  instantiation  has  been  edited.  The  component  produced 
by  the  realizer  is  used  as  an  argument  to  the  storcige  layer  modify  com- 
posite operation  to  replace  the  component  with  the  edited  component.  This 
operation  is  wrapped  in  the  function  called  realize  edits  in  the  runtime  layer. 

3.2    Formalization  of  the  Runtime  Layer 

The  runtime  model  depends  on  the  notion  of  an  instantation  which  is  the 
visual  representation  of  some  component.  Each  instantiation  has  a  unique 
instantiation  id  from  the  given  set  IID. 

[IID] 

An  instantiation  consists  of  a  base  instantiation  which  "represents"  a  com- 
ponent, a  sequence  of  link  markers  which  "represents"  the  anchors  of  the 
component,  and  a  function  mapping  link  markers  to  anchor  ids. 

[BASE.INSTANTIA TION,  LINK A RKER] 

INSTANTIA  TION  

base  :  BASEJNSTANTIATION 

links  :  seq  LINK^KfARKER 

link  Anchor  :  LINKJ^ARKER     ANCHOR -ID 

dom  linkAnchor  =  ran  links 


A  user  manipulates  instantiations,  so  that  there  must  be  a  way  of  map- 
ping from  instantiations  to  components.  The  function  variable  instants  in 
the  SESSION  schema  defined  below  maps  an  instantiation  id  to  a  pair  con- 
sisting of  an  instantiation  and  the  UID  of  its  corresponding  component. 
The  accessor  function  in  the  HYPERTEXT  schema  then  maps  these  UIDs 


-120- 


to  components.  More  than  one  instantiation  may  be  associated  with  the 
same  UID  and  hence  with  the  same  component. 

A  hypertext  is  manipulated  in  a  session  which  is  model  by  the  SESSION 
schema.  The  OPERATION  free  type  names  the  various  operations  a  user 
can  perform  during  a  hypertext  session. 

OPERATION  ::=  OPEN  \  CLOSE 

I   PRESENT  I  UNPRESENT 

I   CREATE  I  EDIT  \  SAVE  \  DELETE 

During  a  session,  a  user  opens  up  one  or  more  instantiations  of  hypertext 
components  through  which  the  hypertext  may  be  modified.  We  use  the  term 
presents  to  denote  opening  up  an  instantiation  on  a  component  because  the 
component  is  presented  to  the  user  by  means  of  the  instantiation.  Instanti- 
ations are  not  only  a  function  of  the  component  which  they  represent,  and 
two  presentation  specifiers  —  one  implicitly  from  the  component's  complnfo 
and  the  other  explicitly,  either  user  given  or  from  a  link  specifier  —  but  also 
implicitly  of  the  "current"  set  of  instantiations.  The  function  instantiator 
which  is  part  of  the  schema  SESSION  captures  this  relationship.  In  sav- 
ing the  result  of  a  series  of  edits,  the  reverse  of  the  instantiator  function  is 
needed;  we  call  this  function  a  realizer  function.  It  takes  an  instantiation 
and  returns  a  component  based  on  the  current  session. 

There  are  some  component  specifiers  which  can  only  be  resolved  at  run- 
time. An  example  of  such  a  specifier  is  "the  last  node  visited."  The  storage 
layer  should  be  independent  of  such  component  specifiers.  We  introduce 
the  notion  of  a  run-time  resolver  which  is  just  an  extension  of  the  regular 
resolver  function.  Note  that  the  invariants  on  anchors  given  in  the  schema 
for  HYPERTEXT  only  apply  to  those  component  specifiers  which  are  in 
the  domain  of  H .resolver.  Also  the  LinksToAnchor  function  will  not  give 
those  links  with  component  specifiers  resolvable  only  at  run-time  (not  in 
the  domain  of  H .resolver)  —  these  additional  links  must  be  captured  in  the 
run-time  layer. 


-121- 


SESSION  

H  :  HYPERTEXT 

history  :  seq  OPERATION 

instants  :  IID  >^  {INSTANTIATION  x  UID) 

instantiator  :  UID  x  PRESENT^PEC  INSTANTIATION 

realizer  :  INSTANTIATION  ^  COMPONENT 

runTimeResolver  :  COMPONENT^PEC  UID 

head{history)  =  OPEN 
V  uid  :  UID;  ps  :  PRESENT ^SPEC  \ 
uid  €  ^om  H .accessor  • 

realizer {instantiator{md,ps))  =  H .accessor{uid)  A 
H .resolver  C  runTimeResolver 


A  SESSION  

SESSION 
SESSION' 

^history'  =     history  -\-  1 
instantiator'  =  instantiator 
realizer'  =  realizer 


A  session  begins  with  an  existing  hypertext  (storage  system)  and  a  clean 
instantiation  slate. 

 openSession  

SESSION 

hypertextl  :  HYPERTEXT 

H  =  hypertext'] 
history  =  {OPEN) 
instants  =  0 


Because  there  are  several  operations  which  can  open  up  a  new  instan- 
tiation, we  introduce  the  following  function  which  opens  up  a  set  of  new 
instantiation  on  an  existing  set  of  component. 


-122- 


openComponents  : 

SESSION  X  V {SPECIFIER  x  PRESENT ^PEC) 
-  SESSION 

V5  :  SESSION;  specs  :  f  (SPECIFIER  x  PRESENT ^PEC)  • 
3  5'  :  SESSION;  iids  :¥  IID; 

new  Instants  :  IID  >+♦  (INSTANTIATION  x  f//Z))  | 
5'.^  =  5.F  A 

S' .runTimeResolver  =  S .runTimeResolver  A 
S'. history  =  S. history  ^  (PRESENT)  A 
S' .instants  =  S. instants  ©  newlnstants  A 
#n'ds  =  i^specs  A  ifds  fl  dom  S. instants  =  0  A 
dom  newlnstants  =  iids  A 
(V  5  :  5pec5  • 

3  iid  :  nrfs;  uicf  :  UID; 

cs  :  COMPONENT-SPEC; 
ps  :  PRESENT-SPEC; 
inst  :  INSTANTIATION  \ 

cs  =  {first(s)).componentSptc  A 

p5  =  5econ<i(5)  A 

uid  =  S .runTimeResolver(cs)  A 

I'risi  =  S .instantiator(uid,ps)  • 

newlnstants{iid)  =  (inst, uid))  • 
openComponents(S y  specs)  =  5' 


—pre  sent  Component  

spec?  :  SPECIFIER 
presentSpecl  :  PRESENT  SPEC 

eSESSION'  = 

openComponents(6  SESSION  ,{(spec1 ,  presentSpecl)]) 


We  can  also  follow  a  link  from  a  given  link  marker  in  a  given  instantiation 
and  present  all  the  components  for  which  the  associated  link(s)  has(have) 
specifiers  with  a  "TO"  direction.  There  may  be  more  than  one  link  involved 
because  there  may  be  more  than  one  link  associated  with  a  particular  anchor. 


-123- 


 foUowLink  

A  SESSION 
iidl  :  IID 

linkMarkerl  :  LINKJ^ARKER 

3  aid  :  ANCHORED;  links  :  F  LinkComp- 

specs  :  ¥  {SPECIFIER  x  PRESENT-SPEC)  | 
aid  =  {first{instants{iidl))).linkAnchor{linkMarker?)  A 
links  =  H  .accessor^LinksToAnchor{n , 

s€cond{instants{iid'!)),  aid)^  A 
^rsi^5pecs[|  =  {s  :  SPECIFIER  \  3  linkc  :  LinkComp  \ 

linkc  G  links  •  5  €  ran(/mA;~(6a5e(/m^c))).sp€CJ_/zer5}  A 
(Vs  :  spec5  •  {first{s)). direction  =  TO  A 

second{s)  =  {fiTst{s)).presentSp€c)  • 
eSESSION'  = 

op€nCompon€nts{d SESSION ,  specs) 


Opening  up  a  new  instantiation  on  a  newly  created  component  is  mod- 
eled by  the  newComponent  schema. 

 newComponent  

A  SESSION 

component  :  COMPONENT 
baseComp'^  :  BASE.COMPONENT 
psi  :  PRESENT-SPEC 
presentSpecl  :  PRESENT-SPEC 

history'  =  history  "  (CREATE) 

{H' ,  component)  =  CreQteNewComponent{n ,baseComp1  ,ps1) 
3  uid  :  UID;  xnst  :  INSTANTIATION;  iid  :  IID  \ 
iid  ^  dom  instants  • 

inst  =  instantiator{uid .  presentSpec?)  A 
uid  =  H' .accessor^ {component)  A 
instants'  =:  instants  ©  {I'lirf  (m5<, 


The  schema  unPresent  models  the  removal  of  an  instantiation. 


-124- 


 unPresent  

ASESSION 
iidi  :  I  ID 

H'  =  H 

history'  =  history  ^  { UNPRESENT) 
instants'  =  {iidl}  ^  instants 


Instantiations  can  be  modified  by  editing  them.  Editing  an  instantiation 
does  not  cause  a  change  in  its  corresponding  component.  An  explicit  save 
operation  is  required  to  save  the  result  of  an  edit  (or  many  edits). 

 editlnstantiation  

ASESSION 

instantiation!  :  INSTANTIATION 
iidi  :  IID 

H'  =  H 

history'  =  history  ^  (EDIT) 
iidi  €  dom  instants 
instants'  =  instants® 

{iidi  ^-+  {instantiation? ,  s€cond{instants{iid'!)))} 


 realizeEdits  

ASESSION 
iidi  :  IID 

history'  =  history  {SAVE) 
instants'  —  instants 

3  c  :  COMPONENT;  inst  :  INSTANTIATION;  uid  :  UID 
inst  =  first{instants{iidl))  A 
uid  =  s€Cond{instants{iid'!))  A 
c  =  realizer{inst)  • 
H'  =  ModifyComponent{  H ,  uid,c) 


To  be  complete  we  must  allow  a  component  to  be  deleted.  Since  a 
component  is  identified  by  its  instantiation,  the  component  to  be  deleted 
must  have  been  instantiated.  We  also  must  remove  any  other  instantiations 
for  that  component. 


-125- 


deleteComponent  

^SESSION 
iidl  :  IID 

history'     history  ^  {DELETE) 
iid'^  €  dom  instants 

3  uid  :  UID  j  uid  -  second{instants{%id1))  • 
H'  =  DeleteComponent{H ,  uid)  A 
instants'  —  {jttf?}  instants 


A  session  finlly  ends  when  it  is  closed  out.  Notice  that  the  default  is  not 
to  save  the  results  of  any  changes  to  instantiations. 

 closeSession  

A  SESSION 

H'  =  H 

history'  =  history  (CLOSE) 
instants'  =  0 


We  can  model  a  read-only  SESSION  with  the  following  schema: 

RE  A  D.ONL  Y -SESSION  

SESSION 

{SA  VE,  CREA  TE,  DELETE}  n  ran  history  =  0 


4    Conformance  with  the  Reference  Model 

One  reason  to  have  a  reference  model  for  hypertext  is  to  try  to  answer  the 
ascertain  whether  a  purported  hypertext  system  actually  warrants  being 
called  a  hypertext  system.  So,  given  an  actual  hypertext  system  how  do  we 
show  that  it  meets,  or  is  conformant  with  the  model?  The  best  guidance  for 
answering  this  question  comes  from  the  VDM  experience  under  the  heading 
of  data  reification  as  described,  for  example,  in  Chapter  8  of  Cliff  Jones' 
book  [13]  on  software  development  using  VDM.  First,  we  must  exhibit  total 
functions,  called  retrieve  functions  which  map  the  actual  types  and  functions 
from  given  (actual)  hypertext  system  to  each  of  the  following  types  and 
functions  of  the  model.  We  must  also  demonstrate  adequacy  -  that  there 


-126- 


is  at  least  one  actual  representation  for  each  abstract  value.  Obviously,  the 
retrieve  functions  must  satisfy  the  invariants  which  are  given  for  the  data 
types  and  functions.  An  informal  way  of  saying  this  is  that  everything  which 
is  expressible  or  realizable  in  the  model  must  be  expressible  or  realizable  in 
the  actual  system. 

In  actuality  our  model  is  much  more  powerful  than  necessary.  In  partic- 
ular 

•  By  admitting  multi-way  links  and  links  to  links  in  the  model,  we  put 
a  fairly  heavy  burden  on  any  implementation. 

•  Many  hypertext  systems  do  not  have  the  notion  of  composites. 

•  Some  hypertext  systems,  such  as  KMS,  do  have  not  have  links  with 
both  an  explicit  source  and  destination.  Thus  requiring  discrimination 
amongst  all  the  values  of  type  DIRECTION  is  too  much. 

We  are  currently  working  on  a  "minimal"  model  which  address  the  above 
items  and  others  as  may  be  necessary. 

The  following  list  summarizes  the  given  sets  (base  types),  abstract  types, 
functions,  and  operations  which  must  have  actual  realizations  in  a  hypertext 
system  conforming  to  the  model. 

1.  GivenSets. 
UID 

COMPONENT-SPEC 

PRESENT-SPEC 

ANCHOR-ID 

ANCHOR^VALUE 

ATOM 

ATTRIBUTE 

VALUE 

IID 

BASE-INSTANTIATION 
LINK-MARKER 

2.  Abstract  types. 


-127- 


DIRECTION 
ANCHOR 

SPECIFIER 
LINK 

COMP_INFO 

BASE_COMPONENT 

COMPONENT 

HYPERTEXT 

INSTANTIATION 

OPERATION 

SESSION 

3.  Storage  layer  functions. 

CreateNewComponent 

DeleteComponent 

ModifyComponent 

AttributeValue 

SetAttributeValue 

AIlAttributes 

LinksToAnchor 

4.  Runtime  layer  operations  (schemas). 

openSession 

present  Component 

followLink 

newComponent 

unPresent 

editlnstantiation 

realizeEdits 

deleteComponent 

closeSession 


-128- 


5    Concluding  Remarks 


Development  of  the  Dexter  model  is  still  in  its  very  early  stages.  As  discussed 
in  Section  4,  the  model  as  currently  stated  is  far  more  powerful  than  any 
existing  hypertext  system.  The  provisions  for  n-ary  links  and  for  composite 
nodes,  for  example,  are  intended  to  accomodate  the  design  of  future  hyper- 
text systems.  No  existing  system  that  we  have  examined  includes  both  n-ary 
links  and  composite  nodes.  The  result  is  that  no  existing  system  'conforms 
to'  the  model  in  the  sense  that  it  supports  all  of  the  mechanisms  that  the 
model  supports.  The  solution  to  this  problem  is  to  make  some  mechanisms 
'optional',  resulting  in  a  family  of  interrelated  models  that  support  differing 
sets  of  optional  mechanisms.  The  weakest  model,  for  example,  would  have 
no  composites  and  only  binary  links.  The  strongest  model  would  be  the 
Dexter  model  in  the  present  form.  Conformance  to  the  model  could  then  be 
condition alized  on  the  exact  set  of  mechanisms  supported.  Systems  would 
be  compared  on  the  basis  of  the  set  of  mechajiisms  that  they  do  support. 

A  related  issue  involves  a  number  of  consistency  restrictions  that  the 
present  model  imposes.  For  example,  when  creating  a  link  the  model  re- 
quires that  all  of  its  specifiers  resolve  to  existing  components.  This  restric- 
tion prevents  the  creation  of  links  that  are  'dangling'  from  the  outset.  The 
model  does  not,  however,  include  any  restrictions  that  prevent  the  creation 
of  dangling  links  via  the  deletion  of  linked-to  components.  This  restriction 
adequately  represents  the  consistency  guarantee  of  KMS.  But  its  is  overly 
restrictive  for  Augment,  which  allows  creation  of  initially  dangling  links.  In 
contrast,  its  is  not  restrictive  enough  for  NoteCards  and  HAM  which  pre- 
vent dangling  links  at  all  times.  As  in  the  case  of  mechanisms,  restrictions 
of  this  sort  will  have  to  be  made  optional  in  the  model.  Conformance  to  the 
model  can  then  be  conditionalized  on  appropriate  choices  of  restrictions.  As 
in  the  case  for  mechanisms,  systems  can  compared  on  the  basis  of  the  set  of 
restrictions  that  they  enforce. 

The  model  has  yet  to  be  compared  in  detail  to  the  hypertext  systems 
it  is  designed  to  represent.  Clearly,  a  necessary  step  in  the  development 
of  the  model  is  to  formally  specify  (in  Z)  the  architecture  ajid  operation 
of  a  number  of  'reference'  hypertext  systems  using  the  constructs  from  the 
Dexter  model.  These  reference  systems  should  be  chosen  to  represent  a 
broad  spectrum  of  designs,  intended  application  domains,  implementation 
platforms,  etc.  This  enterprise  would  provide  valuable  feedback  regarding 
the  adequacy  and  completeness  of  the  model.  In  particulaj,  it  will  help 
asess  whether  the  model  provides  sufficient  mechanisms  for  representing  the 


-129- 


<hyp«rtext> 

<coBpon«nt> 

<type>  text  </typ«> 
<uid>  21  </uid> 

<diata>  This  is  soa«  t«zt  ....  </data> 
<anchor> 

<id>  1  </id> 

<location>  13  </location> 

</anchor> 
</co«ponent> 
<coHponent> 

<type>  text  </typ«> 

<uid>  777  </uid> 

<data>  This  is  son*  other  text  ....  </data> 
<anchor> 

<id>  1  </id> 

<location>  13-19  </location> 
</anchor> 
</coiq>on«nt> 
<C0Bf>onent> 

<typ«>  link  </typ«> 
<uid>  881  </uid> 
<sp«cifier> 

<coBponent_uid>  21  </coBponent_uid> 
<anchor_id>  1  </anchor_id> 
<direction>  FROM  </direction> 
<\8pacifier> 
<specif i«r> 

<coi«ponent_uid>  777  </component_uid> 
<anchor_id>  1  </anchor_id> 
<direction>  TO  </direction> 
<\8p«cif ier> 
</co«ponent> 
</hypertext> 


Figure  5:  Example  of  a  trivial  interchange  format  derived  from  the  model. 

important  (common)  abstractions  found  in  the  reference  systems.  It  will 
also  provide  feedback  on  the  'naturalness'  of  the  model,  i.e.,  on  whether 
the  specification  of  the  reference  systems  in  Dexter  terms  feels  'natural' 
or  whether  the  abstractions  found  in  certain  systems  must  be  excessively 
massaged  to  fit  into  the  Dexter  abstractions. 

Despite  its  early  stages  of  development,  the  model  has  already  been 
useful  in  developing  hypertext  interchange  standards.  As  described  in  the 
panel  on  interchanging  hypertexts  at  the  Hypertext  89  Conference  [16],  a 
number  of  efforts  have  been  started  to  operationalize  the  abstractions  of 
the  Dexter  model  in  the  form  of  interchange  formats.  Figure  5  shows  an 


-130- 


example  of  one  such  format.  This  format  was  used  for  experimenting  vv., 
the  interchange  of  hypertexts  between  NoteCards  and  HyperCard.  As  can 
be  seen  from  the  figure,  the  format  is  a  fairly  straightforward  rendering  of 
the  entities  found  in  the  Dexter  model  into  a  SGMLish  syntax.  This  format 
is  by  no  means  a  well- developed  interchange  standard.  But  it  does  suggest 
that  the  Dexter  model  provides  a  good  basis  from  which  to  develop  such 
standards.  In  fact,  because  the  model  is  an  attempt  to  provide  a  well-defined 
and  comprehensive  model,  it  is  an  ideal  basis  for  developing  a  comprehensive 
standard  for  interchanging  hypertexts  between  widely  differing  systems. 


-131- 


References 


[1]  Akscyn,  R.,  McCracken,  D.L.,  Yoder,  E.A.  KMS:  A  distributed  hy- 
pertext for  managing  knowledge  in  organizations.  Communications  of 
the  ACM,  31(7),  1988,  820-835. 

[2]  Campbell,  B.  &  Goodman,  J.M.  HAM:  A  general  purpose  hypertext 
abstract  machine.  Communications  of  the  ACM,  31(7),  1988,  856-861. 

[3]  Conklln,  J.  Hypertext:  A  survey  and  introduction.  IEEE  Computer, 
20(9),  1987,  17-41. 

[4]  Delisle,  N.  &  Schwartz,  M.  Neptune:  a  hypertext  system  for  CAD  ap- 
plications. Proceedings  of  ACM  SIGMOD  '86,  Washington,  D.C.,  May 
28-30,  1986,  132-142. 

[5]  Englebart,  D.C.  Authorship  provisions  in  Augment.  Proceedings  of  the 
IEEE  COMPCON,  Spring,  1984,  465-472. 

[6]  Englebart,  D.C.  Collaboration  support  provisions  in  Augment.  OAC 
Digest:  Proceedings  of  the  1984  AFIPS  Office  Automation  Conference, 
Los  Angeles,  February  20-22,  1984,  51-58. 

[7]  Feiner,  S.,  Nagy,  S.,  &  van  Dam,  A.  An  experimental  system  for  creating 
and  presenting  interactive  graphical  documents.  ACM  Transactions  on 
Graphics,  1(1),  1982,  59-77 

[8]  Goodman,  D.  The  Complete  HyperCard  Handbook.  New  York:  Bantam 
Books,  1987. 

[9]  Halasz,  F.G.,  Moran,  T.P.,  &  Trigg,  R.H.  NoteCards  in  a  nutshell.  Pro- 
ceedings of  the  1987  ACM  Conference  of  Human  Factors  in  Computer 
Systems  (CHI+GI  '87),  Toronto,  Ontario,  April  5-9,  1987,  45-52. 

[10]  Halasz,  F.G.  Reflections  on  NoteCards:  Seven  issues  for  the  next  gen- 
eration of  hypermedia  systems.  Communications  of  the  ACM,  31(7), 
1988,  836-855. 

[11]  Proceedings  of  Hypertext  87,  Chapel  Hill,  NC,  November  13-15,  1987. 
Available  from  ACM  Press,  order  number  608892. 

[12]  Proceedings  of  Hypertext  89,  Pittsburgh,  PA,  November  5-8,  1989. 
Available  from  ACM  Press,  order  number  608891. 


-132- 


[13]  Jones,  C.B.  Systematic  Software  Development  Using  VDM.  Prentice- 
Hail  International,  Hertfordshire,  England,  1986. 

[14]  Lange,  D.B.  A  formal  approach  to  hypertext  using  post-prototype  for- 
mal specification.  Dept.  of  Computing  Science,  Technical  University  of 
Denmark,  Oct.  31,  1989. 

[15]  Meyrowitz,  N.  Intermedia:  The  architecture  and  construction  of  an 
object-oriented  hypermedia  system  and  applications  framework.  Pro- 
ceedings of  the  Conference  on  Object-oriented  Programming  Systems, 
Languages,  and  Applications  (OOPSLA  '86),  Portland,  OR,  Septem- 
ber 29  -  October  2,  1986,  186-201. 

[16]  Oren,  T.  Panel:  Interchanging  hypertexts.  Proceedings  of  Hypertext  89, 
Pittsburgh,  PA,  November  5-8,  1989,  379-381. 

[17]  Pearl,  A.  Sun's  Link  Service:  A  protocol  for  open  linking.  Proceedings 
of  Hypertext  89,  Pittsburgh,  PA,  November  5-8,  1989,  137-146. 

[18]  Shneiderman,  B.  Hypertext  on  Hypertext.  Addison-Wesley:  New  York, 
1989. 

[19]  Spivey,  J.M.  The  Z  Notation.  Prentice-Hall  International,  Hertford- 
shire, England,  1989. 

[20]  Trigg,  R.H.  &  Weiser,  M.  TEXTNET:  A  network-based  approa<:h  to 
text  handling.  ACM  Transactions  on  Office  Information  Systems,  4(1), 

1986,  1-23. 

[21]  Walker,  J.  Document  Examiner:  Delivery  interface  to  hypertext  docu- 
ments. Proceedings  of  Hypertext  87,  Chapel  Hill,  NC,  November  13-15, 

1987,  307-323. 

[22]  Walker,  J.  Supporting  document  development  with  Concordia.  IEEE 
Computer,  21(1),  1988,  41-59. 

[23]  Yankelovich,  N.,  Haan,  B.,  Meyrowitz,  N.,  k  Drucker,  S.  Intermedia: 
The  concept  and  the  construction  of  a  seamless  information  environ- 
ment. IEEE  Computer,  21(1),  1988,  81-96. 


-133- 


STANDARDIZATION  OF  HYPERMEDIA: 
WHAT'S  THE  POINT? 


A  Position  Paper 

Hypertext  Standardization  Workshop 

National  Institute  of  Standards  and  Technology 
National  Computer  Systems  Laboratory 
January  16-18,  1990 


Shoshana  L.  Hardt-Komacki,  Louis  M.  Gomez,  John  F.  Patterson 

Bellcore 
445  South  Street 
Morristown,  NJ  07960-1910 
(201)  829-4528  shoshi@bellcore.com 


Abstract 

In  this  paper  we  present  multiple  views  on  the  issue  of  standardi- 
zation of  Hypermedia  systems  that  operate  over  a  global  hetero- 
geneous information  network.  To  aid  our  analysis  we  introduce 
a  reference  model  that  captures  the  information  flow  and  the 
information  control  aspects  from  Ae  viewpoint  of  the  user.  This 
model  is  then  used  to  focus  the  analysis  of  Hypermedia  systems 
from  a  variety  of  perspectives,  such  as  overall  resources,  network 
communication,  interface  building,  and  application  writing. 
Based  on  our  analysis  we  conclude  that  at  this  time,  the  com- 
ponents of  Hypermedia  systems  that  are  ready  for  standardiza- 
tion are  not  necessarily  Hypermedia- specific.  Moreover,  we 
strongly  believe  that  the  Hypermedia-specific  aspects  of  these 
systems  are  not  yet  ready  for  standardization  and  we  question  the 
wisdom  of  ever  standardizing  certain  Hypermedia  specific  com- 
ponents such  as  the  user  interface  or  the  navigation  tools.  In 
addition,  we  conjecture  that  it  may  be  desirable  to  standardize  a 
generic  set  of  tools  that  can  be  used  to  build  these  components  so 
as  to  guarantee  that  the  access  to  the  information  stored  in  future 
Hypermedia  systems  will  not  be  impaired. 


-135- 


ANGLES  ON  STANDARDIZATION 


Intrinsic  to  the  quest  for  standardization  is  the  desire  to  make  artifacts  designed  by  different  peo- 
ple in  different  places  at  different  times  compatible  in  relation  to  some  predefined  tasks.  If  we 
ask  why  one  should  attempt  to  standardize  HyperText  and  Hypermedia  technologies,  we  should 
look  for  the  answer  in  efforts  to  combine  pieces  of  information,  text,  graphics,  still  images, 
audio,  video,  animation  and  the  like,  which  were  created  by  different  people  in  different  places 
at  different  times.  From  this  perspective  it  follows  that  it  is  reasonable  to  consider  such  standard- 
ization efforts  only  if  we  are  willing  to  view  the  system  as  operating  on  a  veiy  large  heterogene- 
ous network. 

Multimedia  is  a  very  complex  artifact.  It  requires  large  amounts  of  resources  and  human 
involvement.  Because  of  its  potential  as  a  new  medium  in  which  the  human  can  seek,  express 
and  control  knowledge,  human  interface  consideradons  are  of  crucial  importance.  Much  of  the 
complexity  involved  in  running  the  support  hardware  and  software  that  make  Hypermedia  sys- 
tems a  reality  must  remain  hidden  from  the  human  and  should  proceed  automatically.  This 
implies  the  smooth  and  efficient  transfer  of  information  and  control  between  many  machines, 
each  with  its  own  capabilities  for  communication  and  information  handling.  Furthermore,  it 
implies  that  the  overall  speed  of  the  composite  system  should  remain  mostly  unaffected  by  the 
global  configuration  of  the  various  information  sources  and  conduits  to  enable  synchronization. 

The  standardization  of  an  artifact  as  complex  as  Hypermedia  involves  the  standardization,  or  at 
least  a  thorough  understanding,  of  the  evolutionary  trends  existing  today  in  the  Hypermedia  sup- 
porting technologies.  Any  attempts  to  freeze  a  version  of  a  rapidly  evolving  system  should  be 
carefully  engineered  so  as  to  guarantee  uninterrupted  progress.  Therefore,  one  of  the  more 
important  challenges  is  to  decide  which  aspects  of  Hypermedia  need  to  become  a  standard  and 
which  aspects  are  better  off  left  alone.  This  decision  should  be  based  on  a  model  of  the  func- 
tionality of  the  system,  a  model  flexible  enough  to  allow  unexpected  technological  develop- 
ments. To  illustrate  this  point  let  us  consider  two  extreme  scenarios  for  Hypermedia  functional- 
ity. In  the  first  scenario  a  single  user  is  running  a  standalone  application  on  a  workstation.  In 
the  second  scenario  a  user  is  running  a  shared  application,  which  includes  real-time  communica- 
tion via  broadband  networks  with  other  users  and  with  a  variety  of  infonnation  gateways  to  dis- 
tributed data  sources.  Undoubtedly,  the  complexity  of  the  issue  of  standardization  and  its  impli- 
cations on  information  sharing  are  of  different  proportions  in  the  two  scenarios.  In  the  first  case, 
standardization  must  guarantee  the  compatibility  of  applications  in  many  present  and  future 
environments.  In  the  second  case,  standardization  will  guarantee  complete  information  sharing 
across  authors,  users  and  machines.  It  is  the  second  scenario  which  can  benefit  the  most  from 
standardization  and  at  the  same  time  is  in  the  most  fragile  developmental  phase  and  hence 
requires  special  handling. 

There  are  at  least  three  reasons  to  embark  on  standards  efforts.  First  it  may  be  valuable  to  come 
to  some  agreement  on  a  Hypermedia  independent  environment  which  will  support  this  brand  of 
computation.  Second,  standards  may  focus  on  the  representation  of  data  objects  use  in  Hyper- 
media applications.  And  third,  a  standards  effort  might  concentrate  its  energy  providing  a  stan- 
dard human  interface  for  applications  that  are  browsing  and  information  retrieval  intensive. 

With  respect  to  the  first  point,  a  standard  reference  model  which  supports  Hypermedia  almost 


-136- 


certainly  shares  many,  if  not  all,  its  attributes  with  reference  models  for  most  other  applications. 
It  may  be  useful,  however,  for  Hypermedia  practitioners  to  determine  where,  in  a  layered  refer- 
ence model  Hypermedia  applications  exert  most  of  their  impact.  Later  in  this  paper  we  outline  a 
general  reference  model  to  facilitate  discussion  of  this  sort. 

Hypermedia  applications  are  intimately  concerned  with  data  objects  of  various  types  and  their 
interrelation.  Because  of  their  complex  linking  structure  and  multiple  media  flavor.  Hypermedia 
applications,  in  all  likelihood,  require  that  data  objects  have  detailed  and  explicit  representations. 
Rich  and  flexible  standard  representations  will  be  of  great  value  to  Hypermedia  implementers  in 
matters  of  exchange  and  authoring.  It  is  also  tlie  case,  however,  that  these  very  same  objects 
(e.g.  image,  video)  and  their  underlying  representations  are  also  critical  to  many  other  classes  of 
applications  where  exchange  is  important  but  has  nothing  to  do  with  Hypermedia.  Therefore,  we 
question  the  prudence  of  Hypermedia-based  object  presentation  standards.  It  would  seem  that 
Hypermedia  practitioners  should,  again,  consider  the  unique  impact  that  hypertext  applications 
might  have  on  current  and  emerging  object  presentation  standards  efforts.  We  offer  some  con- 
jectures in  this  regard  in  the  context  of  a  reference  model. 

While  the  defining  characteristic  of  Hypermedia  is  its  linking  structure,  its  most  often  cited 
benefit  is  as  an  aid  to  human  intellect.  It  may  be  reasonable  then,  for  Hypermedia  practitioners  to 
look  for  standards  in  the  human  interface  to  realize  this  cognitive  benefit.  We  conjecture  that  this 
route  is  at  best  premature  and  at  worst  naive.  A  standard  Hypermedia  human  interface  is  prema- 
ture simply  because  there  does  not  exist  very  much  solid  information  about  the  sorts  of  Hyper- 
media design  features  that  people  find  helpful.  This  state  of  affair  makes  it  virtually  impossible 
to  code  high  level  standards  which  could  sensibly  and  practically  apply  to  the  multiplicity  of 
potential  Hypermedia  applications.  Readiness  aside,  such  a  standards  quest  may  not  be  prudent. 
The  target  domain  of  an  application  often  changes  fundamental  qualities  of  its  interface.  Given 
the  complexity  of  Hypermedia  application  domains,  it  may  be  more  prudent  to  build  highly 
stereotype  applications  optimized  for  the  communication  and  problem  solving  needs  of  a  partic- 
ular domain  rather  than  a  vanilla  consistent  interface  that  does  not  accommodate  the  rich  varia- 
tion in  Hypermedia  applications. 

In  this  paper,  we  center  our  discussion  around  a  view  of  the  Hypermedia  system  from  the  user's 
perspective.  If  we  follow  the  information  and  control  as  they  flow  from  the  user's  terminal  to  the 
actual  database,  we  cross  at  least  eight  functional  levels.  These  levels  are  described  in  the  next 
section,  followed  by  an  illustration  of  their  descriptive  power  in  two  examples  of  prototype  Mul- 
timedia systems.  This  illustration  is  followed  by  a  discussion  of  the  Hypermedia  system  from 
other  perspectives  and  the  implications  of  this  decomposition  into  levels  on  standardization. 


A  REFERENCE  MODEL  FROM  THE  USER'S  VIEWPOINT 

Like  many  other  dynamic  systems  with  a  high  degree  of  complexity.  Hypermedia  can  be  viewed 
from  multiple  perspectives.  Each  perspective  reveals  a  dimension  along  which  hierarchical 
description  levels  can  be  stacked  and  interdependencies  between  structure  and  function  revealed. 


-137- 


Level  6 

File  System 

Level  5 

Virtual  File  System 

Level  4 

Virtual 

Presentation  Objects 

Interprocesses 

Broadband 

Level  3 

Communication 

Dialogue/Applications 

Mechanism 

Network 

Level  2 

Virtual  Terminal 

Level  1 

Actual  Terminal 

Figure  1 

Six  Plus  Two  Level  Reference  Model  Describing  the  Passage  of  Information  and  Control 
From  the  User  at  the  Actual  Terminal  to  the  Actual  Information  Source.  We  View 
Level  3  and  4  as  the  Only  Hypermedia  Specific  Levels. 


Imagine  the  way  a  Hypermedia  system  looks  from  the  perspective  of  the  user.  From  this  per- 
spective, both  information  and  control  are  conveyed  through  layers  of  interpretation  until  they 
reach  their  destination  which,  in  this  case,  is  an  arbitrary  collection  of  actual  file  systems  created 
by  arbitrary  authors  and  located  at  remote  sites  which  may  be  unknown  to  the  user.  We  chose  to 
separate  the  path  of  information  and  control  into  eight  independent  layers,  each  with  its  own  set 
of  primitive  operations  and  data  elements.  Consequently,  implicit  to  the  construction  of  this 
reference  model  is  the  assumption  that  the  functionality  of  the  overall  system  is  decomposable. 
However,  keep  in  mind  that  many  complex  artifacts  are  only  nearly  decomposable,  namely,  their 
actual  implementation  involves  "mixing"  of  levels  due  to  strong  pragmatic  considerations. 
Therefore,  we  consider  this  model  an  idealization  which  serves  as  a  general  guideline  during 
system  design  and  evaluation. 


-138- 


In  Figure  1  we  introduce  the  eight  level  model  and  represent  it  as  a  "six  plus  two"  level  model. 
This  is  because,  the  virtual  interprocess  communication  mechanism  and  its  actual  network 
implementation  can  be  involved  in  the  information  transmission  process  anywhere  along  the 
path  between  the  actual  terminal  and  the  actual  file  system  and  hence  could  not  be  placed  in  any 
particular  location  on  the  stack. 

Undoubtedly,  the  reference  model,  at  the  level  of  detail  shown  in  Figure  1,  may  describe  any 
interactive  distributed  computer  system.  This  raises  the  question  of  where  do  we  perceive  the 
Hypermedia  specific  components  of  the  system  to  reside.  In  attempting  to  answer  this  question 
one  may  realize  that  any  computer  system,  when  examined  very  closely,  exhibit  many  of  what 
one  may  consider  at  least  Hypertext  specific  characteristics.  For  example,  the  Unix®  file  system 
provides  much  of  the  functionality  of  a  Hypertext  system,  without,  perhaps,  a  sylized  user  inter- 
face. We  will  return  to  this  point  shortly,  after  we  briefly  review  the  levels  shown  in  Figure  1. 

The  bottom  two  levels  in  Figure  1  describe  the  terminal  and  the  virtual  terminal.  Like  all  virtual 
devices,  the  virtual  terminal  provides  a  level  of  description  that  is  implementation  independent. 
The  primitive  operations  comprising  the  virtual  device  description  are  implemented  in  every 
device  to  the  best  of  that  device's  actual  capabilities.  Like  all  virtual  devices,  it  represents  an 
additional  level  of  processing  of  information,  which  is  the  price  one  must  pay  for  flexibility. 
With  the  virtual  terminal  level  of  description,  dialogues  (applications)  can  be  constructed  (level 
3)  that  are  implementable  on  the  virtual  terminal  and  which  have  as  primitive  operations  user 
interaction  activities.  The  dialogue  level  is  the  "information  browsing"  level  and  the  value  of 
separating  it  from  the  virtual  terminal  level  is  that  it  enables  the  application  writer  to  tailor  the 
interface  to  the  applications  and  to  the  targeted  user  community  in  a  terminal  independent 
fashion.  The  level  of  description  of  the  Presentation  Objects  (level  4)  contains  packets  of  infor- 
mation stored  in  a  form  that  can  be  displayed  by  any  interface.  The  database  containing  these 
objects  is  represented  in  level  5.  Notice  that  operations  at  each  level  in  the  stack  except  the  top 
three  are  represented  in  terms  of  primitive  operations  of  the  level  below  it.  In  the  case  of  the  top 
three  levels,  which  are  separated  in  Figure  1  by  a  double  line,  the  order  is  reversed.  This  is 
because  the  presentation  objects  are  implemented  in  terms  of  the  virtual  file  system,  and  the  vir- 
tual file  system  is  implemented  in  terms  of  the  actual  file  system.  This  reversal  property  is  an 
essential  part  of  any  description  scheme  that,  similar  to  our  scheme,  follows  the  path  of  informa- 
tion and  control  between  the  user  and  some  real  data  —  the  scheme  has  to  start  with  a  real  object, 
namely  the  terminal,  and  end  with  a  concrete  implementation  of  data.  We  will  not  to  elaborate 
on  the  actual  implementation  levels  of  the  file  system. 

Which  of  the  above  levels  are  part  of  the  Flypermedia  application  and  which  levels  describe  the 
environment?  In  our  work  we  view  the  Presentation  Objects  and  the  interface  (levels  3  and  4)  as 
part  of  Hypermedia  and  they  will  be  discussed  in  more  details  in  the  next  section.  We  view  the 
other  description  levels  as  representing  the  supporting  infrastructure  for  global  Hypermedia  sys- 
tems and  for  most  other  applications.  Currendy,  this  supporting  infrastructure  is  not  standard- 
ized, e.g.,  the  virtual  terminal  and  the  virtual  file  system  are  not  standards,  and  broadband  com- 
munication networks  are  far  from  standardized.  Given  this  view,  one  may  question,  as  we  did  in 
the  first  section,  the  wisdom  of  standardizing  Presentation  Objects  and  aspects  of  interi'aces 
before,  at  least,  stable  sketchs  of  a  standard  virtual  terminal  and  a  standard  virtual  file  system  are 
agreed  upon. 


-139- 


In  the  next  section  we  will  examine  standardization  issues  from  various  viewpoint,  but  before 
doing  so  we  illustrate  the  value  of  the  reference  model  presented  in  Figure  1  in  two  examples. 
To  demonstrate  how  the  reference  model  provides  structure  to  the  functionality  of  Hypermedia 
systems,  we  look  at  the  following  two  systems  from  the  domain  of  Customized  Electronic  Infor- 
mation Delivery.  Customized  Electronic  Information  Delivery  systems  provide  users  with  vari- 
able information  streams.  Regarding  the  level  of  editing  of  the  information  items  delivered  by 
such  systems  we  can  imagine  two  extremes  —  highly  stylized,  long,  magazine  like,  articles,  and 
short  raw  articles  directly  from  the  news  wires.  The  Electronic  Magazine  (Judd  and  Cruz,  1989) 
is  an  example  of  the  former,  and  the  Passive  Information  Grazing  system  (Bussey  et  al,  1989)  is 
an  example  of  the  latter. 

The  Electronic  Magazine  research  prototype  displays  multimedia  articles  through  a  stylized  user 
interface  providing  the  user  with  navigation  and  orientation  tools.  In  addition,  the  magazine 
contains  multimedia  authoring  tools  and  a  mark-up  language.  Figure  2  presents  a  glance  at  the 
Electronic  Magazine  from  the  perspective  of  the  reference  model  presented  above. 


Actual  Terminal 

Sun-3  Color  Monitor 

Virtual  Terminal 

SunViewNvindow  System 

Dialogue/Applications 

Multimedia  Interface 
Navigation  tools 

Presentation  Objects 

Stylized  Multimedia  Articles 
SGML  Based  Mark-Up  Language 
Authoring  tools 

Virtual  File  System 

Linked  Database  of  Multimedia  Articles 

Actual  File  System 

Unix®  Files 

Virtual  InterProcess 
Communication  Mechanism 

None 

Actual  Network 

None 

Figure  2 

Description  of  the  Elecfronit'  Magazine  Prototype 


SunView  is  a  trademark  of  Sun  Microsystems,  Inc. 
Unix  is  a  registered  trademark  of  AT&T. 


-140- 


Actual  Terminal 

Sun-3  Color  Monitor 

Virtual  Terminal 

X  Window  System'''' 

Dialogue/Applications 

Simple  Divided  Screen 
Navigation  Tools 

Presentation  Objects 

Unedited  Multimedia  News  Items 

Virtual  File  System 

Categorized  Articles 

Actual  File  System 

The  Oracle  Database 

Virtual  InterProcess 
Communication  Mechanism 

None 

Actual  Network 

EXPANSE  (see  Bussey  et  al  1989). 

Figure  3 

Description  of  the  Passive  Information  Grazing  Prototype 


The  research  prototype  of  the  Passive  Information  Grazing  System  provides  the  user  with  a  con- 
tinuous stream  of  multimedia  information  through  a  simple  interface.  Before  reaching  the  user 
the  information  passes  through  a  filter  eliminating  articles  that  according  to  a  personalized  user 
profile,  are  of  no  interest  to  the  user.  Figure  3  shows  a  brief  overview  of  the  system  from  the 
perspective  of  the  reference  model. 


INTERSECTING  DIMENSIONS  AND  STANDARDIZATION  ISSUES. 

Hypermedia  systems  require  a  very  rich  infrastructure.  Even  though  they  may  be  viewed  as 
mere  application  programs,  they  put  a  severe  strain  on  existing  computational  and  communica- 
tion resources.  They  push  today's  technologies  to  their  limits.  Therefore,  when  it  comes  to  stan- 
dardization it  may  be  ill  advised  to  consider  Hypermedia  as  a  standalone  application  and  not  as  a 
system  that  is  closely  coupled  with  the  development  of  its  infrastructure.  For  example,  from  the 
viewpoint  of  resources,  the  actual  performance  and  capabilities  of  the  system  are  affected  by 
resources  available  at  each  of  the  levels  described  in  Figure  1.  Parameters  such  as  network  relia- 
bility and  speed,  information  storage  capacity,  CPU  "horse  power",  and  tenninal  capabilities 

X  Window  System  is  a  trademark  of  IvHT. 


-141- 


may  play  a  major  role  in  defining  the  future  shape  of  Hypermedia  applications. 

Keeping  the  Hypermedia  dependencies  on  its  infrastmciui^e  in  mind,  we  will  proceed  to  discuss 
Hypermedia  and  its  standardization  from  the  view  point  of  the  Hypermedia  application  writer, 
According  to  the  reference  model  presented  in  Figure  1,  the  application  writer  is  equipped  with 
terminal  independent  and  file  system  independent  authoring  tools.  In  our  framework,  the  appli- 
cation writer  is  responsible  for  producing  the  Presentation  Objects,  and  the  User  Interface.  The 
Presentation  Objects  are  the  key  elements  of  the  system.  A  collection  of  them  resides  in  the  vir- 
tual file  system,  and  they  are  displayed  on  the  interface.  Aspects  of  their  structure  are  given  in 
Figure  4. 


Object  Description: 
links 
attributes 
authorization 
displaying  methods 

Object  Presentation: 
envelope 
body 


Figure  4 

The  Structure  of  Presentation  Objects. 

It  is  important  to  note  that  in  the  context  of  the  current  discussion,  the  Presentation  Objects  pro- 
vide a  way  to  cai"ve-up  meaningful  presentable  pieces  of  multimedia  information.  This  is  due  to 
the  fact  that  the  Presentation  Objects  contain  sufficient  specification  to  guarantee  that  they  can 
be  displayed,  classified,  stored,  retrieved,  and  filtered  in  a  global  Hypennedia  system.  Also, 
they  essentially  represent  an  "Object  Oriented  Approach"  to  Hypermedia  information  represen- 
tation and  management. 

We  view  Presentation  Objects  as  consisting  of  two  main  parts  ~  the  Description  part  and  the 
Presentation  part.  The  Description  part  contains  the  links  that  the  object  has  to  other  objects, 
attribute  of  the  object  such  as  its  size  and  the  resources  it  needs,  information  about  authorization 
and  authoring  tools,  and  methods  to  display  it.  The  Presentation  part  of  the  object  contains  the 
envelope  and  the  body.  The  envelope  contains  preview  information  about  the  body  of  the 
object,  e.g.  title,  abstract,  video  clip  etc.  The  body  is  (a  pointer  to)  the  content  of  the  object. 

The  level  of  the  dialogue  captures  user  interface  and  session  management  issues.  Some  of  its 
functionality  is  given  in  Figure  5. 


-142- 


Current  Status 
Available  Objects 
Open  Objects 

Navigation  Tools: 

within  object  navigation 
between  objects  navigation 

Authoring  Tools 
Displaying  Tools 


Figure  5 

The  Level  of  the  Dialogue  (Applications) 


CONCLUSIONS 

We  are  now  in  a  position  to  consider  our  central  problem  here:  What  do  we  need  to  standardize 
in  order  to  guarantee  information  sharing  in  Hypermedia  systems  that  operate  over  a  global 
heterogeneous  information  network? 

The  standardization  of  the  virtual  terminal,  the  virtual  file  system,  and  the  virtual  interprocesses 
communication  mechanism  should  come  first.  These  standards  will  guarantee  that  any  applica- 
tion can  run  on  the  standard  virtual  terminal  irrespective  of  the  terminal  and  the  actual  file  sys- 
tem used,  and  that  any  network  can  be  used  for  communication  given  that  it  can  emulate  the  vir- 
tual network.  Regarding  the  Hjrpemiedia  components,  the  Presentation  Objects  should  be  the 
next  in  line  for  standardization.  However,  as  stated  in  the  opening  section,  since  at  the  present 
time  we  still  cannot  assess  the  potential  multimedia  capabilities  of  the  future  we  must  wait  for 
the  above  standards  before  we  consider  freezing  the  form  of  the  Presentation  Objects  and  their 
database. 

If  we  now  look  at  the  situation  where  all  the  levels  in  Figure  1  are  a  standard  except  the  applica- 
tion level  we  immediately  realize  that  there  is  no  point  in  standardizing  it.  The  fact  that  the  lev- 
els above  and  below  it  are  a  standard  impose  a  strong  enough  constraint  that  produces  a  standard 
set  of  tools  to  build  the  software  at  that  level.  This  approach  sets  the  functionality  of  Hyper- 
media but  not  its  "look  and  feel".  We  believe  that  at  this  point  it  is  still  inappropriate  to  stand- 
ardize "look  and  feel"  of  Hypermedia  because  not  enough  is  known  about  the  relationship 


-143- 


between  the  users'  cognitive  skills  and  personal  preferences  and  the  benefits  that  Hypermedia 
has  to  offer  to  them.  Therefore,  at  this  point,  a  standard  user  interface  may  defeat  the  purpose  of 
user-friendliness  and  may  make  personalized  access  to  information  impossible. 


BIBLIOGRAPHY 

Bussey  H.,  Edigo  C.  Kaplan  A.  Rohall  S.  and  Yuan  R.  (1989).  Service  Architecture,  Prototype 
Description,  and  Network  Implications  of  a  Personalized  Information  Grazing  Service.  Submit- 
ted to  Infocom  '90. 

Judd  T.H.  and  Cruz  G.C  (1989).  Customized  Electronic  Magazines  -  Electronic  Publishing  for 
Information  Grazing.  Advanced  Printing  of  Paper  Summaries,  Electronic  Imaging  '89,  Vol.  1, 
pp.  504  -  509. 


-144- 


A  Formal  Model  of  Hypertext* 


Danny  B.  Lange 


Briiel  &  Kjaer  Industri  A/S^ 
DK  -  2850  Naerum,  Denmark 
Tel:  +45  42  80  05  00 
email:  danny.lange@bk.dk 


Department  of  Computing  Science 
Technical  University  of  Denmark 
DK  -  2800  Lyngby,  Denmark 


.t 


January  22,  1990 


Abstract 


In  this  paper  a  formal  specification  of  an  abstract  model  of  hypertext  is  presented. 
The  Vienna  Development  Method  (VDM)  is  used  in  this  specification.  Experiences 
with  a  prototype  hypertext  system  and  studies  of  other  existing  hypertext  systems  are 
captm-ed  in  this  formal  specification.  Basically  datamodel  of  hypertext  is  suggested.  In 
this  model  three  main  abstract  data  types  of  hypertext  are  formally  defined:  nodes, 
networks  and  structures.  The  abstract  data  types  are  applied  to  the  concepts  of  object- 
oriented  databases  and  a  "hyp>erbase"  is  defined. 

1  Introduction 

Hypertext  is  becoming  a  w^ell-known  technique  for  information  representation  and  management.  Differ- 
ent research  projects  show  that  hypertext  has  many  potential  applications  that  are  just  beginning  to 
be  explored:  textbooks,  dictionaries,  encyclopedias  and  software  engineering  [Hypertext  1989].  At  the 
Hypertext'89  Conference  a  wide  range  of  hypertext  products  were  presented.  They  all  covered  many  dif- 
ferent aspects  of  hypertext.  But,  they  had  one  thing  in  common.  When  it  comes  to  means  of  interchange 
and  communication  between  these  systems  they  are  all  doomed  to  fail. 

In  this  jungle  of  different  systems,  publishers  of  hypertexts  must  worry  about  portability  of  their  works 
between  different  hypertext  systems  to  ensure  that  they  don't  depend  to  much  upon  the  success  of  one 
system.  The  users  of  hypertext  systems  must  worry  about  the  supply  of  hypertexts  or  use  of  hypertext 
organization  of  long-lived  project  documentation  stored  in  a  specific  hypertext  system,  making  the  data 
inaccessible  for  other  (hypertext)  systems. 

Steps  toward  interchange  and  communication  between  open  hypertext  systems  must  be  based  on 
formal  and  abstract  models  of  hypertext  to  which  all  existing  and  hopefully  future  systems  can  be 
related.  In  the  last  few  years  an  increasing  number  of  papers  on  hypertext  and  its  application  has 
been  published.  Only  a  very  small  part  of  this  work  has  been  concerned  with  the  formal  treatment 
of  hypertext.  There  is  clearly  a  need  for  a  more  formal  approach  to  hypertext  since  one  can  claim 
that  hypertext  is  driven  by  user  interface  and  implementation  considerations  [Halasz  &;  Conklin  1989]. 
Looking  through  the  Hypertext'89  Proceedings  [Hypertext  1989]  one  will  find  dissapointing  few  pa- 
pers on  the  more  formal  and  abstract  aspects  of  hypertext.  However,  attempts  to  present  more  for- 
mal models  of  hypertext  have  appeared  [Delisle  k  Schwartz  1987]  [Garg  1988]  [Stotts  k  Furuta  1989] 
[Consens  &:  Mendelzon  1989].  This  paper  presents  a  formal  model  of  hypertext,  using  the  Vienna  Devel- 
opment Method  (VDM)  [Bj0rner  k  Jones  1982]  [Jones  1986].  VDM  supports  the  top-down  developmant 

'A  version  of  this  paper  emphasizing  a  formal  specification  methodology  and  with  different  technical  details,  but  in- 
evitably overlapping  in  the  datamodel  facet  with  the  present  paper,  is  being  presented  at  VDM '90  and  pubUshed  in  the 
conference  proceedings  by  kind  permission  of  the  Programme  Comittee  and  the  editors. 

^Author's  Present  Address 

'a  part  of  the  work  has  taken  place  at  the  Technical  University  of  Denmark 


-145- 


Figure  1;  A  Snapshot  of  the  Prototype 


of  software  systems  specified  in  a  notion  suitable  for  formal  verifikation.  The  specifications  are  based  on 
a  datamodel  using  high-level  types  as  set,  list,  map  and  cartesian  products.  Function  specification  are 
written  in  predicate  logic,  using  pre-conditions  stating  the  properties  that  the  inputs  must  satisfy,  and 
post- conditions  which  states  the  relationship  of  inputs  to  outputs. 

At  Briiel  &  Kjaer^  we  have  developed  a  prototype  of  a  hypertext  system.  The  prototype  was  developed 
on  a  SUN3  workstation'  using  an  expert  system  shell  called  ART^.  The  prototype  was  written  partly 
in  ART'S  rule-based  language  and  Common  Lisp  [Steele  1984]  using  a  window  based  user  interface,  see 
figure  1.  The  prototype  has  fulfilled  several  aims.  First  it  has  given  the  developers  a  feeling  of  what 
hypertext  is  all  about,  by  working  with  the  prototype.  Secondly  the  ideas  of  hypertext  has  easily  been 
communicated  to  non-experts  and  potential  users. 

Our  experiences  with  this  prototype  and  studies  of  hypertext  systems  as  HyperCard,  Hyperties,  Nep- 
tune, KMS,  Nodecards,  etc.  is  captured  in  the  formal  specification  presented  in  section  2  and  section 
3  in  this  paper.  In  section  2  the  datamodel  of  hypertext  is  presented  by  domain  equations  giving  a 
formal  definition  of  the  primitives  of  hypertext,  introducing  the  three  main  concepts:  nodes,  links  and 
structures.  In  section  3  the  datamodel  is  extended  with  a  set  of  operations  in  an  object-oriented  way, 
defining  abstract  datatypes  of  nodes,  links  and  structures.  Our  experiences  with  this  formal  model  and 
future  work  are  discussed  and  concluded  in  section  4.  Detailed  pre-/post-  specifications  of  the  specified 
operations  can  be  found  in  appendix  A. 

2    Developing  a  Basic  Datamodel  of  Hypertext 

The  hypertext  datamodel  has  evolved  on  basis  of  the  experience  with  our  prototype  and  our  general 
knowledge  to  the  domain.  The  model  will  include  the  concept  of  nodes  and  their  interior,  links  between 
nodes  and  between  fields  and  buttons  inside  the  nodes.  Different  kinds  of  links  are  described:  N-ary 
links,  second  order  links  and  active  links.  Additionally  the  idea  of  having  structures  organizing  nodes  in 
e.g.  hierarchies,  is  introduced. 

In  the  following  a  datamodel  of  hypertext  is  developed  through  stepwise  refinement.  Initially  the 
meaning  of  hypertext  is  defined  as  a  database  that  has  active  cross-references,  allowing  the  user  to  have 
nonsequential  access  to  a  text  thereby  making  the  reading  process  nonlinear.  A  hypertext  can  be  modelled 
as  a  set  of  nodes  and  a  collection  of  hnks  where  the  nodes  are  documents  and  the  links  are  cross-references. 

^Briiel  &  Kjaer  Industri  is  a  company  that  designs  and  manufactiires  high- precision  electronic  measuring  instruments. 

^Sun  Workstation  is  a  registered  trademark  of  Sun  Microsystems,  Inc. 

''art  (Automated  Reasoning  Tool)  is  a  registered  trademark  of  Inference  Corporation. 


-146- 


Figure  2:  Example  of  linked  nodes 


1.0      Hypertext  ::  Nodes  x  Links 

2.0      Nodes       =  "chunks  of  information" 

3.0      Links        =  "cross-references" 

2.1  Nodes  -  Units  of  Information 

An  information  fragment  in  a  hypertext  is  called  a  node.  Thus,  hypertext  is  made  up  of  a  collection  of 
distinct  named  information  fragments.  Conceptually  this  information  fragment  usually  describes  a  single 
concept  or  topic.  The  names  may  be  assigned  explicitly  by  the  user  or  they  can  be  assigned  automatically. 

In  some  hypertexts  it  might  be  necessary  to  divide  the  nodes  into  several  different  types:  document, 
illustration,  annotation,  etc.  Thus,  it  must  be  possible  to  add  attributes  and  attribute  values  to  nodes. 

4.0      Nodes  =  Nid  frt  (Node  x  Attributes) 
5.0      Node    ::  "information" 
6.0      Nid     ::  TOKEN 

2.2  Links  -  the  Glue  that  Holds  Hypertext  Together 

A  connection  between  tw^o  nodes  is  called  a  link.  When  a  link  is  activated,  say  by  a  mouse  click,  one 
can  jump  to  the  node  the  link  points  to.  A  hypertext  network  is  made  up  of  a  collection  of  uniquely 
named  links.  Links  can  be  used  to  transfer  the  reader  to  an  new  topic,  provide  access  to  an  annotation 
or  footnote,  show  a  reference  and  so  on.  Conceptually  a  link  is  directed,  i.e.  it  points  from  one  node  to 
another,  having  an  origin  called  the  anchor  and  an  end  point  called  the  destination.  However  this  does 
not  mean  that  links  are  unidirectional,  that  is,  the  passage  is  not  only  one-way.  One  can  always  pose  the 
question:  who  points  to  me? 

In  figure  2  one  can  see  an  example  of  a  document  consisting  of  a  section,  two  subsections  and  a 
reference  list.  The  section  is.  connected  to  its  subsections  through  node  to  node  links.  All  three  items 
link  to  a  common  reference  list.  The  section  node  might  contain  the  text  of  the  introduction  to  the  two 
subsections,  and  the  nodes  of  the  subsections,  contains  the  text  of  the  subsections.  Below  the  concept 
of  linking  is  restricted  to  only  concern  connections  between  entire  nodes.  In  section  2.4  the  model  is 
extended  to  include  links  between  the  contents  of  one  node  and  another  node. 

A  hypertext  system  may  have  only  one  type  of  link  or  it  may  have  several  types.  The  link  type  can 
reflect  the  type  of  information  it  is  pointing  to,  making  it  possible  for  the  user  only  to  view  links  of  a 
certain  type.  Different  types  of  links  in  a  document  could  be  references  to  related  articles  or  reviewers 
annotations.  To  represent  this  variety  of  linktypes,  they  can  be  attributed  in  the  same  manner  as  for 
nodes. 


-147- 


Na.me 


Address 


Phone 


Family 


Figure  3:  Example  of  the  use  of  schema 


7.0  Links 

8.0  Link 

9.0  Connections 

10.0  Anchor,  Destination 

11.0  Lid 


=  Lid  -fjt  Link 

::  Connections  x  Attributes 

::  Anchor  x  Destination 

=  Nid 

::  TOKEN 


An  important  point  in  hypertext  is  the  support  for  collaborative  work.  If  several  people  are  reviewing 
and  annotating  the  same  hypertext,  they  all  use  the  common  network  made  by  the  author  of  the  document. 
To  this  common  network  each  individual  can  add  a  personal  subnetwork  reflecting  their  own  need  for 
referencing  across  the  common  network  and  including  references  for  their  annotations.  Looking  at  other 
persons  sub-networks,  one  can  inspect  their  annotations,  possibly  realizing  that  further  comments  on 
specific  topics  are  needless,  thus  saving  time  in  a  review  process.  This  does  not  remove  the  need  for 
attributed  links.  One  may  still  need  to  add  individual  information  to  the  link,  like  the  time  when  it  was 
created,  why  it  was  created,  etc. 


12.0  Networks  =  Nwid  frt  (Links  x  Attributes) 
13.0      Nwid        ::  TOKEN 


2.3    Slots  -  the  Interior  of  the  Node 

Conceptually  the  node  can  cover  a  wide  range  of  applications,  i.e.  representing  a  chapter  or  section  in  a 
document,  function  definitions  in  the  source  text  of  programs,  organizing  information  on  notecards,  etc. 
Obviously  there  is  a  need  for  a  substructure  in  the  interior  of  the  node. 

A  slot  is  a  kind  of  template  for  the  contents  of  the  node.  It  can  be  compared  to  the  record  datatype  in 
programming  languages.  A  node  has  a  collection  of  unique  named  slots,  each  having  some  kind  of  textual 
content.  An  example  of  the  use  of  schema  in  a  node  is  shown  in  figure  3.  In  this  example  information  on 
individuals  is  organized  in  an  archive.  For  each  person  exists  one  basic  "card"  carrying  a  specific  set  of 
information:  name,  address,  phone  and  family.  "Cards"  can  be  annotated  and  one  can  make  references 
between  the  "cards".  In  the  family  slot,  one  can  mention  the  spouse  and  make  a  link  to  his/her  "card". 
In  our  model  theser  "cards"  are  equal  to  the  node. 

Slots  can  be  connection  points  for  links.  As  anchors  and  destinations  they  are  identified  by  the  node 
in  which  they  are  embedded  and  their  name. 


14.0  Node  =  Slid  ^  Slot 

15.0  Slot  ::  String  x  Attributes 

16.0  Stnng  ::  CHAR* 

17.0  Anchor,  Destination  =  ...  |  (Nid  x  Slid) 

18.0  Slid  ::  TOKEN 


-148- 


Figure  4:  Example  of  buttons 


2.4    Buttons  and  Fields  -  the  Referential  Mechanism 

In  this  section  buttons  and  fields  are  introduced.  They  are  the  fundamental  components  of  the  referential 
mechanism,  one  of  the  most  powerful  properties  of  hypertext.  Links  connecting  entire  nodes  and  slots 
have  already  been  introduced.  Now  the  concept  of  hnking  is  extended  to  cover  source  and  destination 
points  inside  the  nodes.  Pragmatically  this  covers  the  referential  use  of  links  in  a  hypertext. 

A  handle  is  a  part  of  the  text  inside  the  slot  to  which  a  hnk  can  be  attached.  This  makes  it  possible 
to  establish  connections  between  the  contents  of  one  node  and  another  node.  A  handle  is  defined  as  a 
consecutive  sequence  of  characters  in  the  textual  contents  of  the  slot.  More  precisely  by  its  character 
position  in  the  text  and  the  span  in  numbers  of  characters. 

When  a  link  is  anchored  to  a  handle,  that  is,  there  is  an  outgoing  link  from  a  handel,  the  text  span 
specified  by  the  handle  is  called  a  button.  In  figure  4  it  is  shown  that  one  can  get  from  an  actual  reference 
in  the  text  to  the  reference  list. 

Fields  are  defined  exactly  in  the  same  way  cis  the  buttons  are.  We  have  chosen  to  distinguish  between 
these  two  of  purely  conceptual  reasons,  thus  having  fields  as  one  of  the  possible  end-points  of  hnks. 

The  domain  of  connections  is  extended  to  include  buttons  and  fields.  From  a  connections  point  of 
view,  a  button  or  field  is  identified  by  the  node  and  slot  in  which  it  is  embedded  and  its  handle  in  that 
slot. 


19.0 

Slot  :: 

Siring  x  Handles  x  Attributes 

20.0 

Handles  = 

Hid  j!t  Region 

21.0 

Region  :: 

Position  X  Length 

22.0 

Position,  Length  :: 

No 

23.0 

Anchor  = 

...  1  Button 

24.0 

Destination  = 

...  1  Field 

25.0 

Button,  Fields  :: 

(Ntd  X  Slid  X  Hid) 

To  continue  the  example,  the  use  of  fields  makes  it  possible  to  follow  a  reference  not  only  to  the 
reference  list  but  to  a  certain  entry  in  this  reference  Hst,  see  figure  5.  Depending  on  the  user-interface 
the  entry,  i.e.  the  field,  is  accentuated. 

2.5    More  on  Links  -  N-ary  Links,  2nd  Order  Links  and  Active  Links 

So  far  only  binary  links  has  been  treated.  Binary  hnks  are  characterized  by  one  link  anchor  and  one 
destination  point.  They  match  the  concept  of  navigating  in  a  hypertext  very  well.  That  is,  if  one  has  an 
end-point  of  a  link,  there  is  only  one  way  to  go,  if  one  choses  to  follow  the  link. 

For  structural  reasons  it  may  be  more  appropriate  to  consider  a  more  general  concept  of  links.  N-ary 
links  have  one  or  more  link  anchors  and  one  or  more  destination  points.  In  the  model  this  means  that 
a  set  of  link  anchors  and  destination  points  are  bound  to  the  same  link.  An  example  of  N-aiy  links  is 
shown  in  figure  6.  In  this  example  three  sections  in  a  document  refer  to  a  certain  article.  Following 
the  links,  one  might  first  be  directed  to  an  entry  in  an  annotated  reference  list,  for  reading  an  abstract, 
and  then  to  the  article  itself.  In  this  way  the  concept  of  7V-ary  links  forms  the  basis  of  following  links 


-149- 


in  several  steps,  that  is  being  directed  to  a  short  description  of  the  destination  before  actually  arriving 
there. 


26.0      Connections  ::  Anchor-set  x  DesUnation-set 

Nodes,  slots  and  fields  have  been  discussed  as  destination  points  for  links.  Links  pointing  at  links, 
called  2nd  order  links,  can  be  used  to  point  at  a  collection  of  connections.  It  might  reflect  that  a  hnk 
itself  is  of  special  interest,  and  that  the  reader  after  being  guided  to  the  link,  can  chose  to  study  the 
anchor  or  destination  of  the  Imk.  Links  are  identified  as  connection  points  by  name  of  the  network  in 
which  they  are  embedded,  and  their  own  name. 

27.0      Anchor,  Desiinaiion  =  ...  |  (Nwid  x  Lid) 

Active  links  are  links  that  have  anchors  or  destinations  that  are  function  denotations.  That  is,  instead 
of  having  hnks  pointing  at  fragments  of  text  they  contain  a  function.  This  function  is  to  be  interpreted 
when  one  is  following  the  link.  This  kind  of  a  link  can  be  used  to  generate  a  view  of  the  data  it  is  anchored 
to.  That  could  be  the  generation  of  a  graphical  representation  of  the  data  each  time  one  is  following 
the  link.  A  function  signature  is  added  to  the  domain  of  anchors  and  destinations.  The  domains  of  the 
arguments  and  the  results  of  the  function  are  not  specified  in  any  further  detail. 

28.0      Anchor,  Destination  —  ...  \  Argument^set  ^  Result-set 
29.0      Argument,  Result      =:  ... 

2.6    Structures  -  the  Organizers  of  Hypertext 

The  hypertext  in  figure  2  represents  the  most  simple  organisation  of  a  hypertext.  This  example  of  a 
hypertext  is  a  set  nodes  connected  by  links.  A  hierarchy  of  nodes  in  a  hypertext  is  another  primitive 
example  of  organising  an  hypertext.  It  is  a  way  of  organizing  information  into  meaningfull  parts  e.g. 
documents  into  sections  and  subsections.  Figure  7  shows  such  a  hierarchy  of  sections  and  subsections  in 
a  document.  The  user  is  usually  free  to  define  information  structures  in  traditionally  hypertext  systems 
as  they  are  needed.  But,  the  novice  user  sometimes  may  require  guidance  by  the  hypertext  itself,  or  one 
may  find  ad  hoc  organisation  of  hypertexts  potentially  dangerous.  The  problem  can  be  solved  by  using 
structures. 

Structures  should  prescribe  an  organization  of  nodes  and  networks.  They  can  conceptually  be  com- 
pared to  the  domain  equations  in  VDM,  introducing  sets,  sequences,  maps  and  the  possibility  of  recursive 
definitions,  e.g.  tree  data  structures.  The  structures  can  form  a  basis  for  an  algebra  for  structured  hy- 
pertext documents  [Giiting  et  al.]. 

The  use  of  the  set-structure  has  already  been  demonstrated  and  fits  well  into  card-like  hypertexts. 
The  map-structure  can  extend  this  unordered  collection  of  cards  with  a  facility  of  direct  access  by  user 
defined  names.  Sequences  can  be  used  to  express  interrelationships  between  nodes  as  the  sequence  in 


Figure  5:  Example  of  Fields 


-150- 


which  they  should  be  visited,  e.g.  chapters  in  a  book.  Defining  these  structures  recursively,  makes  it 
possible  to  make  tree  structures  of  nodes. 

It  should  be  emphasized  that  it  is  not  the  nodes  and  networks  themselves  that  are  organized  in  these 
structures.  The  structures  contains  only  the  names  of  the  nodes  and  networks.  Hence  it  possible  to  reuse 
nodes  and  networks  in  several  structures.  E.g.  one  can  think  of  a  section  or  figure  appearing  in  more 
than  one  book,  and  thus  in  several  structures. 

Structures  can  be  interpretated  by  filters,  to  make  hnear  representations  of  the  hypertext,  e.g.  on 
paper.  A  tree  structure  of  a  book  should  intuitively  be  interpreted  by  a  filter  in  a  top-down  left-to-right 
manner,  so  that  chapter  one  and  the  subsections  of  this  chapter  are  written  out  before  chapter  two  and 
so  on. 

Structures  are  uniquely  identified  by  their  name.  Each  structure  is  characterized  by  having  a  col- 
lection of  substructures,  each  organizing  destinations  into  sets,  sequences  or  maps.  The  substructures 
themselves  have  unique  identities  and  can  be  destinations,  thus  making  it  possible  to  build  more  compli- 
cated structures.  A  structure  has  a  root  that  can  identify  one  of  the  substructures  as  being  the  root  of 
the  structure. 


30 

0 

Structures 

—  Sid  Tft  (Structure  x  Attributes) 

31 

0 

Structure 

=  Subsid  yrt  Substructure 

32 

0 

Substructure 

=  Substruc  X  Attributes 

33 

0 

Substruc 

=  Set  1  Seq  \  Map 

34 

0 

Set 

—  Desttnation-set 

35 

0 

Seq 

—  Destination* 

36 

0 

Map 

=  TOKENiTt  Destination 

37 

0 

Anchor,  Destination 

=  ...  1  Sid  1  (Sid  X  Subsid) 

38 

0 

Sid,  Subsid 

::  TOKEN 

2.7    The  Attributes 

Attributes  are  basically  a  mapping  between  names  of  attributes  and  their  values.  The  names  of  the 
attributes  are  user  defined.  The  values  of  the  attributes  can  be  of  a  simple  text  or  numerical  type, 
but  one  can  also  expect  structured  types  as  known  from  the  attributes  of  attribute  grammars.  Among 
attributes  that  should  be  mentioned  are  version  numbers,  time  for  creation,  access  rights,  protection,  etc. 

39.0      Attributes  =  Attribute  jyt  Value 
40.0      Attribute   ::  TOKEN 
41.0      Value        ::  ... 


2.8    The  Hypertexts  -  Bringing  It  All  Together 

Basically  the  developed  datamodel  says  that  a  hypertext  is  a  collection  of  nodes  and  one  or  more  networks 
connecting  the  nodes  and  a  structure  describing  the  organization  of  the  parts  that  forms  the  hypertext. 


Figure  6:  Example  of  N-ary  links 


-151- 


Figure  7:  Example  of  a  hierarchy 


The  networks  represent  the  referential  links,  that  is  the  explicit  links  connecting  two  or  more  parts  of 
the  hypertext.  The  structures  are  organizing  the  nodes  and  the  networks.  One  can  say  that  there  is 
a  dualism  between  networks  and  structures  in  that  structures  represent  a  kind  of  organizational  links 
between  nodes  in  a  hypertext. 

In  this  way  one  can  represent  several  hypertext  applications  in  a  collection  of  nodes,  simply  by  letting 
the  actual  hypertext  application  apply  a  certain  network  and  a  certain  structure  to  the  nodes.  Then 
actual  buttons  in  a  node  are  first  resolved  by  the  hypertext  application  when  one  or  more  networks  are 
applied  to  it  and  the  node  will  show  different  sets  of  buttons  depending  on  the  applied  networks.  Finally 
a  hypertext  is  defined  as: 

42.0      Hypertext  ::  Nodes  x  Networks  x  Structures 

This  observation  leads  to  the  object-oriented  approach  to  a  model,  defining  the  hyperbase  in  terms 
of  abstract  datatypes,  as  presented  in  the  following  section. 

3    An  Object-Oriented  Model 

Having  seen  the  basic  datamodel  of  hypertext  it  clearly  seems  to  be  an  good  idea  to  follow  an  object- 
oriented  approach  in  the  specification  of  the  semantic  functions.  Nodes,  networks,  and  structures  should 
be  defined  as  abstract  datatypes.  The  domains  of  each  of  these  datatypes  has  already  been  described  in 
the  previous  section. 

In  the  following  a  simple  model  of  an  object-oriented  database  is  presented.  Based  upon  this  model 
the  operations  of  the  abstract  datatypes,  as  introduced  by  the  datamodel  in  the  previous  section,  is 
formally  specified. 

3.1    An  Informal  Model  of  an  Object-Oriented  Database 

The  class  of  an  object  is  the  abstract  data  type  of  the  objects.  Thus  an  object  may  be  thought  of  as 
an  instance  of  a  particular  class.  The  class  defines  the  operations  that  can  be  applied  to  the  object  by 
an  apphcation.  A  class  defines  the  set  of  operations  applicable  to  all  instances  of  that  class  in  terms  of 
names  of  operations  and  types  of  formal  arguments  and  results.  An  implementation  of  a  class  provides  a 
set  of  operation  procedures  implementing  the  set  of  operations  defined  by  the  class.  The  implementation 
encapsulates  the  data  representation  and  the  algorithms  that  are  used  to  perform  the  operations.  The  data 
represention  of  an  object  is  a  collection  of  data  that  makes  up  the  state  of  the  object.  The  state  is  managed 
by  the  implementation  and  is  only  accessible  by  means  of  the  operation  procedures  [Crawley  1986]. 

Below  the  basic  domain  of  an  object-oriented  database  is  modelled  as  a  collection  of  instantiated 
objects  each  having  an  unique  identity.  An  instantiated  object  has  a  state  that  can  be  changed  through 
the  set  of  class  operations.  The  domain  of  the  state  and  the  set  of  class  operations  are  defined  by  the 
type  definition  of  the  class. 


-152- 


Hyperbase 


Nodes         Networks  Structures 


Figure  8:  The  Clciss  Hierarchy 


43.0 
44.0 
45.0 
46.0 
47.0 
48.0 


Objecibase 

Object 

State 

Opes 

Ope 

Args,  Res 


Objid  Jff  Object 
State  X  Opes 

Opeid  -nt  Ope 
Args  ^  State  ^ 


(State  X  Res) 


3.2    An  Object-Oriented  Hyperbase 

Now  the  domain  of  hyperbases  are  apphed  to  the  concepts  of  object-oriented  databases.  The  hyperbase 
covers  basic  operations  on  instances  as  the  creation  of  new  instances,  basic  object  version  management 
and  object  access  control. 

An  object-oriented  hyperbase  is  in  this  way  defined  as  a  collection  of  uniquely  named  instances  of 
three  object  types.  Each  instance  has  a  state  which  type  depends  on  the  type  of  the  object.  The  three 
applicable  state  type  are  node,  network  and  structure,  as  defined  in  the  datamodel.  A  set  of  operations 
are  defined  for  each  type.  Furthermore  each  instance  has  a  set  of  predecessors  and  successors,  identifying 
the  neighbours  of  the  instance  in  the  version  chain. 


49.0 

HyperBase 

=  Objid  Jff  Object 

50.0 

Object 

::  State  x  Operations  x  Attributes  x 

Succ-set  X  Pred-set 

51.0 

State 

=  Node  1  Links  |  Structure 

52.0 

Objid 

=  Nid  1  Nwtd  1  Sid 

53.0 

Operations 

=  Opeid  Tft  Operation 

54.0 

Operation 

=  Araument-set  ^  State  ^  (State  x 

Result-set) 

55.0 

Opeid 

::  TOKEN 

3.2.1     Fundamental  Operations 

The  CreatelnstanceOf  operation  can  make  instances  of  the  subclasses,  that  is,  it  can  make  node,  network 
and  structural  objects,  returning  the  unique  names  of  these  objects.  These  instances  can  be  destroyed  by 
the  Destroylnstance  operation.  The  collection  of  identities  of  instances  of  a  given  class  can  be  collected 
by  the  SetOflnstances  operation. 


56.0     ObjectClass      =  Nodes  |  Networks  |  Structures 


-153- 


57.0      type;  CreatelnstanceOf :  ObjectClass  ^  Hyperhase  ^  (Objid  x  Hyperbase) 
.1      type;  Destroy  Instance  :  Objid  ^  Hyperbase  ^  Hyperbase 
.2      type;  SeiOf Instances  :  ObjectClass  ^  Hyperbase  ^  Objid-set 

3.2.2  Basic  Object  Version  Mangagement 

This  set  of  functions  refer  to  the  version  management  of  the  hyperbase.  The  CreateSuccessorOflnstance 
creates  a  copy  of  a  specified  object  instance.  The  identity  of  the  created  object  instance  in  added  to 
the  successor  set  of  the  specified  instance,  which  identity  on  the  other  hand  is  added  to  the  predecessor 
set  of  the  new  object  instance.  The  predecessor  and  successor  sets  of  an  instance  are  found  respectively 
by  the  PredecessorOflnstance  and  5wccessorO//?is<ance  operations.  The  Mer^e/nsiances  operation  merge 
two  objects  into  one  object. 

58.0  type.'  CreateSuccessorOflnstance  :  Objid  ^  Hyperbase  ^  (HyperBase  x  Objid) 

.1  type;  PredecessorOflnstance  :  Objid  ^  Hyperbase  ^  Objid-set 

.2  type .•  SuccessorOflnstance  :  Objid  ^  Hyperbase  ^  Objid-set 

.3  type;  Mergelnstances  :  Objid  x  Objid  ^  Hyperbase  ^  (HyperBase  x  Objid) 

3.2.3  Object  Access  Control 

The  Open  operation  are  concerned  with  checking  the  access  conditions  of  the  instance  before  allowing 
access  to  the  set  of  operations.  The  close  operation  reset  the  access  conditions  after  they  have  been 
altered  by  a  previous  open.  One  has  access  to  the  operations  of  the  hyperbase  objects  through  the 
OperateOnlnstance  function.  The  identity  of  the  object  instance  and  the  name  of  the  operation  to  be 
executed  is  passed  to  this  function. 

59.0      type;  Open  :  ... 
.1      type;  Close  :  ... 

.2      type;  OperateOnlnstance:  Objidx  Opeidx  Argument-set^  HyperBase^  fHyperBasex  Result-set ) 

3.2.4  Object  Attribute  Operations 

AddAttribute  adds  an  named  attribute  to  the  set  of  attributes  of  the  slot.  Attributes  are  removed  by  the 
RemoveAttribute  operation.  Values  are  assigned  to  attributes  by  the  AssignAttribute  operation.  Finally 
a  value  of  an  attribute  is  read  by  using  Read  Attribute. 

60.0  type;  AddAttribute  :  (Objid  x  Name)  ^  Node  ^  Node 

.1  type;  RemoveAttribute  :  (Objid  x  Name)  ^  Node  ^  Node 

.2  type;  AssignAttribute  :  (Objid  x  Name  x  Value)  ^  Node  ^  Node 

.3  type;  ReadAttribute  :  (Objid  x  Name)  ^  Node  ^  Value 

3.3    The  Three  Object  Classes  of  a  Hyperbase 

The  three  object  classes  or  abstract  datatypes  of  a  hyperbase  represent  the  nodes,  the  networks  and  the 
structures. 

3.3.1     A  Node  Class 

The  objects  of  the  node  class  are  having  zero  or  more  slots.  The  operations  are  divided  into  three  groups. 
The  first  set  of  operations  is  grouped  around  the  schema  of  the  node,  and  the  second  set  is  grouped 
around  the  end-point  of  links:  handles  and  regions.  The  final  group  of  operations  is  the  node  attributes 
operations. 


-154- 


Slot  Operations.  The  A ddS lot  operation  adds  a  new  and  empty  slot  to  the  node  instance.  The  identity 
of  the  new  slot  is  returned  to  the  user.  The  RemoveSloi  operation  can  remove  a  slot  and  its  contents 
from  the  node.  One  can  use  the  RetumSlots  operation  to  get  set  of  names  of  the  slots  allocated  in  the 
schema  of  a  node  instance. 

61.0      tx£e.-  AddSlot  :  ()  ^  Node  ^  (Node  x  Slid) 
.1      type;  RemoveSloi  :  Slid  ^  Node  ^  Node 
.2      type.-  RetumSlots  :  ()  ^  Node  ^  Shd-set 

Slot  Browsing  Operations.  The  contents  of  a  specified  slot  can  be  delivered  ais  a  string  of  characters 
by  using  SlotView.  Slotlnsert  is  an  example  of  an  editing  operation.  One  can  use  this  operation  for 
insertion  of  a  string  into  a  position  in  the  contents  of  a  specified  slot.  SloiDeleie  can  be  used  to  remove 
a  specified  portion  text  of  the  contents  of  a  slot. 

62.0     type;  SlotVtew  :  Slid  ^  Node  ^  STRING 

.1      type;  Slotlnsert  :  (Slid  x  STRING  x  Position)  ^  Node  ^  Node 

.2      type;  SlotDelete  ;  (Slid  x  Position  x  Length)  ^  Node  ^(Node  x  Hid-set) 

Handle  Operations.  A  handle  can  be  added  to  a  specified  region  of  the  contents  of  a  slot  by  the 
AddHandle  operation.  The  handle  is  given  a  unique  identity  which  is  returned  to  the  user.  One  can  add 
several  handles  to  the  same  region,  and  regions  can  be  overlapping.  A  handle  is  removed  by  using  Remove- 
Handle.  The  names  of  the  handles  located  in  a  slot  are  returned  by  ReturnPositionHandles  operation, 
and  the  names  of  the  handles  at  a  specified  position  in  a  slot  is  returned  by  the  ReturnPositionHandles 
operation.  The  region  specified  by  a  handle  is  returned  by  the  GetHandle  operation. 

63.0  type;  AddHandle  :  (Slid  x  Region)  ^  Node  — >  (Node  x  Hid) 

.1  type;  RemoveHandle  :  (Slid  x  Hid)  ^  Node  ^  Node 

.2  type;  ReturnSlotHandles  :  Slid  ^  Node  ^  Hid-set 

.3  type;  ReturnPositionHandles  :  (Slid  x  Position)  ^  Node  ^  Hid-set 

A  type;  GetHandle  :  (Slid  x  Hid)  ^  Node  ^  Region 

The  Slot  Attribute  Operations.  AddAitribute  adds  an  named  attribute  to  the  set  of  attributes  of 
the  slot.  Attributes  are  removed  by  the  Remove  Attribute  operation.  Values  are  assigned  to  attributes  by 
the  AssignAttribute  operation.  Finally  a  value  of  an  attribute  is  read  by  using  Read  Attribute. 

64.0  type;  AddAttribute  :  (Slid  x  Name)  ^  Node  ^  Node 

.1  type;  RernoveAttribute  :  (Slid  x  Name)  ^  Node  ^  Node 

.2  type;  AssignAttribute  :  (Slid  x  Name  x  Value)  ^  Node  ^  Node 

.3  type;  ReadAttnbute  :  (Slid  x  Name)  ^  Node  ^  Value 

3.3.2    A  Network  Class 

The  operations  of  the  network  class  consists  of  six  network  changing  operations  and  three  querying 
operations. 

Network  Changing  Operations.  The  AddLink  operation  adds  a  new  and  empty  Unk  to  the  network. 
The  operation  gives  the  link  a  unique  identity  which  is  returned  to  the  user.  A  link  i  removed  by  the 
RemoveLink  operation.  The  anchors  and  destinations  of  the  link  in  question,  does  not  have  to  be  empty. 
Anchors  and  destinations  are  added  to  a  specified  link  by  the  two  operations:  Add  An  char  and  Add- 
Destination.  Removing  anchors  or  destinations  are  done  by  the  RemoveAnchor  and  RemoveDestinaiion 
operations. 


-155- 


65.0  type;  AddLink  :  ()  ^  Links  ^  (Links  x  Lid) 

.1  type;  RemoveLink  :  Lid  ^  Links  ^  Links 

.2  type;  AddAnchor  :  (Lid  x  Anchor)  ^  Links  ^  Links 

.3  type;  RemovcAnchor  :  (Lid  x  Anchor)  ^  Links  ^  Links 

A  type;  AddDesiinaiion  :  (Lid  x  Destination)  ^  Links  ^  Links 

.5  type;  RemoveDestination  :  (Lid  x  Destination)  ^  Links  ^  Links 

Network  Querying  Operations.  The  two  querying  operations  Having  Anchor  and  HavingDestination 
are  used  to  identify  the  links  of  a  certain  network  instance,  that  haye  the  specified  anchors/destination 
in  common.  The  ReadLink  operation  reads  the  anchor  and  destination  set  of  the  specified  hnk. 


66.0      type;  HavingAnchor  :  Anchor^  Links  ^  Lid-set 

.1      type;  HavingDestination  :  Destination  ^  Links  ^  Lid-set 

.2      type;  ReadLink  :  Lid  ^  Links  ^  (Anchor-set  x  Destination-set) 

The  Link  Attribute  Operations.  AddAttribute  adds  an  named  attribute  to  the  set  of  attributes 
of  the  specified  hnk.  Attributes  are  removed  by  the  Remove  Attribute  operation.  Values  are  assigned  to 
attributes  by  the  AssignAttribute  operation.  Finally  a  value  of  an  attribute  is  read  by  using  ReadAttribute. 

67.0  type;  AddAttribute  :  (Lid  x  Name)  ^  Links  ^  Links 

.1  type;  RemoveAttribute  :  (Lid  x  Name)  ^  Links  ^  Links 

.2  type;  AssignAttribute  :  (Lid  x  Name  x  Value)  ^  Links  ^  Links 

.3  type;  ReadAttribute  :  (Lid  x  Name)  ^  Links  ^  Value 

3.3.3    A  Structural  Class. 

The  operations  of  a  structure  are  divided  into  four  groups.  The  first  is  concerned  the  more  general 
operations  on  the  structure,  i.e.  adding  and  removing  substructures  etc.  The  final  three  groups  are 
concerned  with  the  specific  operations  of  the  three  types  of  substructures:  sets,  sequences  and  maps. 


Structure  Operations  A  substructure  can  be  added  to  the  structure  by  using  the  AddSubstructure 
operation.  A  substructure  is  removed  by  RemoveSubstructure.  The  of  identities  of  the  substructures 
pointing  the  specified  destination  is  returned  by  the  HavingDestination  operation.  Finally,  one  can  get 
the  type  of  a  substructure  by  using  the  GetSub structure  Type  operation. 

68.0  Sub  structure  Type  =  Set  |  SEQUENCE  |  Map 

69.0  type;  AddSubstructure  :  SubsiructureType  ^  Structure  ^  (Structure  x  Subsid) 

.1  type;  RemoveSubstructure  ;  Subsid  ^  Structure  ^  Structure 

.2  type;  HavingDestination  :  Destination  ^  Structure  ^  Subsid-set 

.3  type;  GetSub structureType  :  Subsid  ^  Structure  ^  SubstructureType 


Set  Operations  The  AddDestination  operation  adds  a  destination  to  a  set  of  destination.  A  destination 
element  of  a  set  i  removed  by  RemoveDestination.  The  HavingDestinationSet  operation  can  be  used 
to  find  out  whether  a  specified  destination  is  in  the  set.  The  set  of  destinations  is  returned  by  the 
GeiDestinationSet  operation.  One  get  the  number  of  elements  in  the  set  by  using  the  GetCardinality 
operation. 


70.0  type;  AddDestination  :  (Subsid  x  Destination)  ^  Structure  ^  Structure 

.1  type;  RemoveDestination  :  (Subsid  x  Destination)  —>  Structure  ^  Structure 

.2  type;  HavingDestinationSet  :  (Subsid  x  Destination)  ^  Structure  ^  BOOL 

.3  type;  GetDestinationSet  :  Subsid  ^  Structure  ^  Destination-set 

.4  type;  GetCardinality  :  Subsid  ^  Structure  ^  No 


-156- 


Sequence  Operations.  One  can  insert  a  destination  at  the  specified  position  in  the  hst  by  using 
the  InsertDestination  operation.  Destinations  positioned  at  a  position  greater  or  equal  to  the  insertion 
point,  are  shifted  one  place.  By  the  Remove Desiinaiion  operation  one  can  remove  the  destination  at  the 
specified  position.  The  operation  works  in  the  opposite  way  of  the  inserting  operation.  The  operation 
returns  all  the  positions  of  the  specified  destination  in  the  sequence.  The  destination  at  the  specified 
position  is  returned  by  GetDesiination.  GeiLengih  returns  the  length,  i.e.  the  number  of  destinations  in 
the  list. 

71.0      type;  InsertDestination  :  (Suhsid  x  Destination  x  Noj  ^  Structure  ^  Structure 
.1      type;  RemoveDestination  :  (Suhsid  x  Nq)      Structure  ^  Structure 
.2      type;  Having  Destination  :  (Suhsid  x  Destination)  ^  Structure      \i  o-set 
.3      type;  GetDesiination  :  (Suhsid  x  'No)  ^  Structure  ^  Destination 
A     type;  GetLength  :  Suhsid  ^  Structure  No 

Map  Operations.  A  new  named  destination  is  added  by  the  AddDestination  operation  and  removed 
by  the  RemoveDestination.  All  the  names  of  a  specified  destination  can  be  found  by  Having  Destination. 
One  can  get  the  destination  identified  by  a  given  name  by  using  the  GetDesiination  operation.  The  set 
of  names  bound  to  destinations  is  returned  by  GetDomain. 

72.0  type;  AddDestination  :  (Suhsid  x  Name  x  Destination)  ^  Structure  ^  Structure 

.1  type;  RemoveDestination  ;  (Suhsid  x  Name)  ^  Structure  ^  Structure 

.2  type;  Having  Destination  :  (Suhsid  x  Destination)  ^  Structure  ^  Name-set 

.3  type;  GetDesiination  :  (Suhsid  x  Name)  ^  Structure  ^  Destination 

.4  type;  GetDomain  :  Suhsid  ^  Structure  ^  Name-set 

The  Structure  Attribute  Operations.  AddAttrihute  adds  an  named  attribute  to  the  set  of  attributes 
of  the  structure.  Attributes  are  removed  by  the  Remove Aitrihuie  operation.  Values  are  assigned  to 
attributes  by  the  Assign  Aitrihuie  operation.  Finally  a  value  of  an  attribute  is  read  by  using  ReadAtirihute. 

73.0  type;  AddAttrihute  :  (Suhsid  x  Name)  ^  Structure  ^  Structure 

.1  type;  RemoveAttrihute  :  (Suhsid  x  Name)  ^  Structure  ^  Structure 

.2  type;  AssignAitrihute  :  (Suhsid  x  Name  x  Value)  ^  Structure  ^  Structure 

.3  type;  ReadAtirihute  :  (Suhsid  x  Name)  ^  Structure  ^  Value 

4  Conclusion 

One  of  the  major  decisions  in  the  development  of  this  model  has  been  to  separate  the  presentation  and 
the  browsing  semantics  from  the  model,  and  move  them  to  the  applications  design.  The  applications 
should  only  operate  on  the  hyperbase  through  the  specified  operations  and  the  dataobjects  should  not 
be  aware  of  the  applications  and  their  semantics.  By  adding  the  aspects  of  persistence  to  this  object- 
oriented  model  we  have  a  model  of  an  object-oriented  database.  In  this  way  issues  on  distribution, 
basic  version  management  and  access  control  could  be  solved  in  the  domain  of  object  management 
systems.  It  is  our  intention  to  combine  this  model  with  the  european  standard  on  portable  common 
tool  environments  (PCTE)  [Thomas  1989].  PCTE  is  a  standard  for  object-oriented  bases  for  software 
engineering  environments. 

We  are  currently  making  a  prototype  of  a  hyperbase  server  based  on  the  set  of  specifications  presented 
here.  This  prototype  is  developed  in  the  object-oriented  programming  language  C-j--f-.  Diff'erent  hypertext 
applications  are  being  developed  for  this  server  to  show  feasability  of  the  model. 

With  respect  to  the  work  on  hypertext  standardization,  this  model  should  be  related  to  existing 
approaches  to  hypertext,  to  seek  for  commonality  between  different  approaches  and  to  make  progress 
towards  a  complete  model.  It  is  our  opinion  that  a  hypertext  standard  should  be  defined  in  terms 
of  abstract  datatypes,  to  retain  a  maximum  of  representational  abstraction  from  the  viewpoint  of  the 
hypertext  applications.  An  open  point  in  the  model  is  the  interchange  mechanisms  between  diff'erent 


-157- 


hyperbases.  The  model  has  to  be  extended  with  some  kind  of  protocol  for  the  transfer  of  hypertexts  from 
one  base  to  another. 


References 


[Bj0rner  &  Jones  1982] 


Bj0rner,  D.,  Jones,  C.B.  Formal  Specification  &  Sofitvare  Development. 
Prentice-Hall  International  1982. 


[Consens  &:  Mendelzon  1989]  Consens,  M.P.,  Mendelzon,  A.D.  Expressing  Structural  Hypertext  Queries 

in  GraphLog.  In  Hypertext'89  Proceedings.  Pittsburgh,  Pennsylvania,  USA. 
November  1989. 


[Crawley  1986] 

[Delisle  k  Schwartz  1987] 

[Garg  1988] 

[Giiting  et  al.] 

[Halasz  k  Conkhn  1989] 

[Hypertext  1989] 
[Jones  1986] 

[Steele  1984] 

[Stotts  k  Furuta  1989] 

[Thomas  1989] 


Crawley,  S.  An  Object-Based  File  System  for  Large  Scale  AppHcations.  In 
Software  Engineering  Environments,  ed.  Ian  Sommerville.  Peter  Peregrinus 
Ltd.,  1986. 

Delisle,  N.M.,  Schwartz,  M.D.  Contexts  -  A  Partitioning  Concept  for  Hy- 
pertext. ACM  TOOIS  5,  2,  ppl68-186,  1987. 

Garg,  P.K.  Abstraction  Mechanisms  in  Hypertext.  Communications  of  the 
ACM,  31,  7,  pp862-870,  1988. 

Giiting,  R.H.,  Zicari,  R.,  Choy,  D.M.  An  Algebra  for  Structured  Office 
Documents.  ACM  TOOIS,  7,  4,  ppl23-157,  1989. 

Halasz,  F.,  Conklin,  J.  Issues  in  the  Design  and  Application  of  Hypermedia 
Systems.  Tutorial  at  SIGCHI  89,  Austin,  Texas,  1989. 

Hypertext'89  Proceeding.  Pittsburgh,  Pennsylvania,  USA.  November  1989. 

Jones,  C.B.  Systematic  Software  Development  Using  VDM.  Prentice-Hall 
International  1986 

Steele  Jr.,  G.L.  Common  Lisp  The  Language.  Digital  Press,  1984. 

Stotts,  P.D.,  Furuta,  R.  Petri  Net  Based  Hypertext:  Document  Structure 
with  Browsing  Semantics.  ACM  TOOIS,  7,  1,  pp3-29,  1989. 

Thomas,  I.  PCTE  Interfaces:  Supporting  Tools  in  Software  Engineering 
Environments.  IEEE  Software,  6,  6,  ppl5-23,  1989. 


A    Detail  Specifications 

A.l    An  Object-Oriented  Hyperbase 


74.0  type;  CreaielnsianceOf :  ObjectClass  ^  Hyperbase  -*  (Objid  x  Hyperbase) 

.1  \>xe-CreateInstanceOf( class,  )  ^class  E  {NODES.  NETWORKS.  STRUCTURES  } 

.2  post- CreatelnstanceOf (class,  hyperbase) (objid,  hyperbase' ))  ^ 
.3  let  objid  G  Objid  \  dom  hyperbase  in 

.4  cases  class  : 

.5  Nodes  — >  hyperbase'  —■  hyperbase  U  [mk- Nid(obiid)  ^—>■ 

.6  mk- Obiect([],  NodeOpemtions,  [],  {],  {]], 

.7  Networks  — >  hyperbase'  =  hyperbase  U  [mk- Nwid( o bjid)  i-+ 

.8  mk-Obiect([].  LinksOperations,  [],  {},  {}], 

.9  Structures  — ^  hyperbase'  =  hyperbase  U  [mk-Sid(obnd)  t-^ 

.10  mk-Obi€ct([],  StructureOperaiions,  [],  {},  {}], 


-158- 


75.0  type;  Destroylnstance  :  Objid  ^  Hyperbase  ^  Hyperbase 

.1  pTe-Destroylnstancefobiid,  hyperbase)  ^  objid  €  dom  hyperbase 

.2  yost- DesirovInstance(obiid.  hyperbase) (hyperbase' ))  ^ 

.3  hyperbase'  —  [id  i—>-  (let  mk- Obieci(siaie.  operations,  ss,  ps)  —  hyperbase(id)  'm 

A  mk-Object(state,  operations, 

.5  (objid  G  55— ►  (ss  \  {objid})  U  s^Succ(hyperbase(objid)), 

.6  T  ^  5s;, 

.7  (objid  E  ps— •■  (ps  \  {objid})  U  Sj^Pred(hyperbase(objid)), 

.8  T  ~.p.s;;;] 

76.0  type.-  SetOflnstances  :  ObjectClass      Hyperbase  ^  Objid-sei 

.1  pTe-SetOfInstances(class.  )  ^  c/ass  G  {Nodes,  Networks.  Structures  ) 

.2  Dost- SetOfInstances( class,  hyperbase) (objids))  ^ 
.3  cases  c/ass  ; 

.4  Nodes  — >  objtds  ~  {objid  \  (\f  objid  G  dom  hyperbase )(is-Node( objid)) } 

.5  Networks  — >  objids  —  {objtd  \  (M  objid  G  dom  hyperbase) fis- Links ( objid))  ] 

.6  Stru  CTURES  — >  objids  —  {objid  I  ('V  objid  G  dom  hyperbase) f\s-StructuT'es( ob^id)) } 


A. 1.1  Basic  Object  Version  Mangagement 

77.0  type.'  CreateSuccessorOflnstance  :  Objid  ^  Hyperbase  ^  (HyperBase  x  Objid) 

.1  pTe-CreateSuccessorOfInstance( objid,  hyperbase)  ^  o6jerf  G  dom  hyperbase 

.2  x)ost-CreateSuccessorOfInstance(obiid,  hyperbase)(hyperbase' ,  objid'))  ^ 
.3  let  objid'E  Objid  \  dom  hyperbase  in 

.4  let  mk- Object(state,  operations,  attrs,  ss,  ps)  —  hyperbase  (objid)  in 

.5  hyperbase'  =hyperbase+[objidi-*mk-Object(state, operations, attrs, ss  U  {o6ji(f'},  psj] 

.6  U  [o6n(/^'-^  mk- 0<>?ec<(^s<a<e,  operations,  attrs,  {}, {objid})] 

78.0  type.'  PredecessorOf Instance  :  Objid  ^  Hyperbase  ^  Objid-set 

.1  i>re-PredecessorOfInstance(objid,  hyperbase)  ^  o6jzrf  G  dom  hyperbase 

.2  \)ost-PredecessorOfInstance (objtd,  hyperbase) (objids)  ^  objids  —  s^Pred(hyperbase(obid)) 


79.0      type.'  SuccessorOflnstance  :  Objid  ^  Hyperbase  ^  Objid-set 
.1      v>xe-SuccessorOfInstance()  ^  oftjic?  G  dom  hyperbase 

.2      x>ost-SuccessorOfInstance(objid,  hyperbase) (objids)  ^  objids  —  s^Succ(hyperbase(obid)) 


80.0      type;  Mergelnstances  :  ... 


A. 1.2    Object  Access  Control 


81.0      type;  Open  :  ... 


82.0     type;  Close  :  ... 


83.0  type;  OperaieOnlnstance  :  ObjidxOpeidx  Argumeni^set^ HyperBase^ (HyperBasexResnlt^set) 

.1  pTe-OperateOnInstance(objid,  opeid,  ,  hyperbase)  ^ 

.2  oojirf  G  dom  hyperbase  A  opeirf  G  dom  s-  Operations(hvperbase( objid)) 

.3  post- OperateOnlnstance (objtd,  opeid,  as,  hyperbase) (hyperbase' ,  rs')  ^ 
.4  let  mk-06?ec^/'sfa<e,  operations,  attrs,  ss,  ps)  —  hyperbase(objid)  in 

.5  let  (state',  rs')  —  operations(opeid)(as,  state)  in 

.6  (state'::/:  nil  — ► 

.7  hyperbase' =  hyperbase  +  [objid  >-*  mk-Object(state' ,  operations,  attrs,  ss,  ps)], 

.8  s/a<e'=  nil  -*  hyperbase'  =  hyperbase) 


-159- 


Object  Attribute  Operations. 


84.0  type;  AddAUribuie  :  ... 

85.0  type:  RemoveAUribute  :  ... 

86.0  type;  AssignAUribuie  :  ... 

87.0  type;  ReadAUribute  :  ... 


A. 2    The  Three  Object  Classes  of  a  Hyperbase 
A. 2.1     A  Node  Class 
Schema  Operations. 


88.0  type;  AddSlot  :  ()  ^  Node  ^  (Node  x  Slid) 

.1  pxe-AddSloi()  ^  T 

.2  v>ost-AddSloifnode)( node ' .  slid)  ^ 

.3  let  shd  G  Slid  \  dom  node  in  node' =  node  U  [slid      mk- S I otf<  >,  [],  [])] 


89.0  txEe;  RemoveSloi  :  Slid  ^  Node  ^  Node 

.1  v>Te-RemoveSlot(slid,  node)  ^  slid  €  dom  node 

.2  v>ost- RemoveSloi f slid,  node)(node' )  ^  node'—  node  \  {slid} 

90.0  type;  RtturnSlois  :  ()  ^  Node  ^  Shd-set 

.1  x>Te- ReiurnSloisQ  ^  T 

.2  jiost-ReturnSloisf node)( slids)  ^  s/irfs  —  dom  node 


Slot  Browsing  Operations. 

91.0  type;  SlolView  :  Slid  ^  Node  ^  String 

.1  2I^SlotView(slid,  node)  ^  s/z'rf  E  dom  ?).orfe 

.2  yost-Sloi  Viewfslid.  node)(texi)  ^ 

.3  let  mk-Slot( string,  ,  )  —  node(slid)  in  text  —  string 

92.0  type;  Slotlnsert  :  (Slid  x  String  x  Position)  ^  Node  ^  Node 

.1  X)ve-SloiInsert(slid.  ,  position,  node)  ^ 

.2  shd  G  dom  noc^e  A  Het  mk-5/o^fs^r,  ,  )  =  node(slid)  in  0  <  position  <  len  str  ) 

.3  x>ost- Slotlnsert  (slid,  s,  position,  node)  (node' )  ^ 

.4  (let  mk-^/o^f^feart  handles,  attrs)  =  node(slid), 

.5  mk- Slot  (text ' .  handles',  attrs')  —  node' (slid)  in 

.6  text' =  <  text[i]  \  0  <  i  <  position>  ^  s  "  <  iext[i]  \  position  <  i  <  len  text  >  A 

.7  ('V  Ait/  G  dom  handles)  (let  (^p,     —  handles(hid),  (p',  I')  =  handles'  (hid)  in 

.8  p  +  I  <  position  p'  =  p  A  I'  =  I, 

.9  p  <  position  >p  +  l-^p'=pAl'  =  l+  length, 

.10  position  >  p  -*  p'  =  p  +  length  A  I'  =  I 


-160- 


93.0  type;  SlotDelete  :  (Slid  x  Position  x  Length)  ^  Node  ^(Node  x  Hid-set) 

.1  vie- Slot  Delete  (slid,  position,  ,  node)  ^ 

.2  slid  G  dom  node  A 

.3  (let  mk-Slot(sir,  ,  )  —  node(slid)  m 

.4  ^?  <  position  <  len  5^r  A  position  +  length  <  len  sirj 

.5  x)ost-SlotDelete(slid.  position,  length,  node)  (node',  hids)  ^ 

.6  (\ei  mk- Slot  (text,  handles,  attrs)  —  node(slid), 

.7  mk-Slot(text' ,  handles',  attrs)  —  node' (slid)  m 

.8  text' =  <text[i]  \  0  <  i  <  positio>  '  <text[i]  \  position  +  length  <  i  <  ]en  text>  A 

.9  hids  =  {hid  \  (\/  hid  G  dom  handles)  (let  (p,  I)  =  handles(hid)  in 

.10  position  <  p  A  position  +  length  >  p  +  I)}  ))  A 

.11  dom  handles'  —  dom  handles  \  hids  A 

.12  position  <  p  A  position  -f  length  <  p     ^  p'  —  p  -  position  A  V  =  I, 

.13  position  <  p  A  position  +  length  <  p+l  —*  p'  =  p-positionAl'  =l-(position+length-p), 

.14  p  <  position  A  position  +  length  <  p+l  — <■  p'  =  p  A  I'  =  I  -  length, 

.15  p  <  position  A  p+l  <  position  +  length  — ►  p'  =  p  A  /'—  /  -  (p+l  -  position), 

.16  p+l  <  position  —  p'  —  p  A  V  =  I 

Handle  Operations. 

94.0  type.-  AddHandle  :  (Slid  x  Region)  ^  Node  ^  (Node  x  Hid) 

.1  VTe-AddHandle(slid.  mk-ReQion( pos,  length),  node)  ^ 

.2  slid  G  dom  node  A  (let  mk- Slot(str,  ,  )  =  node(slid)  in  pos+length  <  ]en  str  ) 

.3  post- AddHandle(slid.  region,  node)(node' ,  hid)  ^ 

.4  let  mk-Slot(text.  handles,  attrs)  =  node(slid),  hid  G  Hid  \  dom  handles  in 

.5  node'  =  node  +  [slid  i—<-  mk-Slot(text,  handles  U  [hid      region],  attrs)] 

95.0  type;  RemoveHandle  :  (Slid  x  Hid)  ^  Node  ^  Node 

.1  x)xe-RemoveHandle(slid,  hid,  node)  ^ 

.2  s/zrf  G  dom  node  A  (\et  mk- Slot (  ,handles,  )  —  node(slid)  in  hid  G  dom  handles  ) 

.3  post- RemoveHandle  (slid,  hid,  node)(node' )  ^ 

.4  let  mk-Slot(text,  handles,  attrs)  =  node(slid)  m 

.5  node' =  node  +  [slid  h- >■  mk-Slot(text,  handles  \  {hid'],  attrs)] 

96.0  type;  ReturnSlotHandles  :  Slid  ^  Node  ^  Hid-set 

.1  pxe-ReturnSlotHandles(slid,  node)  ^  slid  G  dom  not/e 

.2  post- ReturnSlotHandles( slid,  node) (hids)  ^  hids  —  dom  s-Handles(node(slid)) 


97.0  type;  ReturnPositionHandles  :  (Slid  x  Position)  ^  Node  ^  Hid-set 

.1  x)Te- ReturnPositionHandles  (slid,  position,  node)  ^ 

.2  s/zrf  G  dom  node  A  (let  mk- Slot(str,  ,  )  =  node(slid)  in  position  <  len  str  ) 

.3  post- ReturnPositionHandles(  .  position) (hids)  ^ 
.4  let  mk- 5/0/ .  handles,  )  =  n  ode  (slid)  'm 

.5  /iz(/s  —  {Airf  G  dom  handles  \  (let  mk- Region (p, I)  —  handles(hid)  in 

.6  p  <  position  <  p+l)} 

98.0  type;  GetHandle  :  (Slid  x  ^  iVo(/e  ^  Region 

.1  pxe-GetHandle(slid,  hid,  node)  ^  s/zrf  G  dom  norfe  A  hid  G  dom  s-Handles(ndoe(slid)) 

.2  post-GetHandle(slid,  hid,  node)(region)  ^ 

.3  let  mk-5/c'</^  ,  handles,  )  —  node(slid)  In  region  —  handles(hid) 


The  Slot  Attribute  Operations. 
99.0     type;  AddAttrihute  :  ... 


-161- 


100.0      type;  RemoveAttribute 


101.0      type;  AssignAttribuie  :  ... 
102.0      type;  ReadAitrihuie  :  ... 
A. 2. 2    A  Network  Class 


Network  Changing  Operations. 

103.0  type.-  AddLink  :  ()  ^  Links  ^  (  Links  x  Lid) 

.1  vie-AddLinkf)  ^  T 

.2  Most- AddLink(links) (links' ,  lid')  ^ 

.3  let  lid'£  Lid  \  dom  links  in  links'  —  links  U  [lid't-^  rnk-Linkfmk-  Connections({  },{} ),[])] 


104.0  type;  RemoveLink  :  Lid  ^  Links  ^  Links 

.1  V)Te-RemoveLink(lid,  links)  ^  lid  G  dom  links 

.2  x>osi- RemoveLink(lid,  links) (links' )  ^  links'—  links  \  {lid} 

105.0  type;  AddAnchor  :  (Lid  x  Anchor)  ^  Links  ^  Links 

.1  pTe-AddAnchor(lid,  ,  links)  ^  lid  G  dom  links 

.2  post- AddAnchor(lid,  anchor,  links) (links' )  ^ 
.3  let  mk- Link(mk-Connections(as,  ds),  aitrs)  —  links(lid)  m 

.4  links'  =  links  -h  [lid  i— +  mk-Link(m\i-Connections(as  U  {ancAor},  ds),  aitrs)] 

106.0  type;  RemoveAnchor  :  (Lid  x  Anchor)  ^  Links  ^  Links 

.1  vie- Remove  Anchor  (lid,  anchor,  links)  ^ 

.2  G  dom  /mA;s  A  (let  mk-  Connections( as,  )  =  links(lid)  in  anchor  €.  as  ) 

.3  Dost- Remove Anchor(lid,  anchor,  links) (links' )  ^ 

.4  let  mk- Link(mk-Conneciionsfas,  ds),  aitrs)  —  links  (lid)  m 

.5  links'—  links  -f  i— >  mk-i/f»A:(ink-Cow»ec<?ong/^a5  \  {anc/ior},  rfs^,  a</rs^] 

107.0  type;  AddDestinaiion  :  (Lid  x  Destination)  ^  Links  ^  Links 

.1  i>xe-AddDestination(lid,  destination,  links)  ^  /z'rf  G  dom  links 

.2  post- AddDestinaiion(lid,  destination,  links) (links' )  ^ 
.3  let  mk-LmA:(mk-Coranec/zow5(^a5,  ds),  aitrs)  =  links(lid)  m 

.4  links'  —  links  +  [lid  i-+  mk-Xmfc(^mk- Connections( as,  ds  U  {destination}),  attrs)] 

108.0  type;  RemoveD esiination  :  (Lid  x  Destination)  ^  Links  ^  Links 

•  1  pre- RemoveDesiination(lid,  destination,  links) (links ' )  ^ 

.2  G  dom  links  A  (let  mk-  Connections( ,  ds  )  —  links(lid)  in  destination  E  ds  ) 

.3  Dost- RemoveDestination(lid,  destination,  links) (links ' )  ^ 

.4  let  mk-XmA:(^mk-Connec^ion5(^as.  rfs^,  attrs)  —  links  (lid)  'm 

.5  links' =  links  -f-  [lid  i—^  ink^Link(mkzConnections(as,  ds  \  {destination}),  attrs)] 

Network  Querying  Operations. 

109.0  type;  LI avmg Anchor  :  Anchor^  Links  ^  Lid-set 

.1  X)Te-HavinQAnchor()  ^  T 

.2  post- Having Anchor(anchor.  links)(lids)  ^ 

.3  /irfs  —  {lid  G  dom  /m^s  |  let  mk-Link(mk-Connections(as.  ),  )  =  links(lid)  in  anchor  G  as} 


-162- 


110.0  type;  Having  Destination  :  Destination  ^  Links  ^  Lid-set 

.1  pre-HavinQDestinationQ  ^  T 

.2  x>osi- H avinoD estination(destination.  links)(lids)  ^ 

.3  lids  =  {/zrfgdom  /m^s|]et  mk-ZmArCmk-Connec<2ons('.(isj.  j  =  links(lid)  in  destination  G  rfs} 


111.0      type."  ReadLink  :  Lid  ^  Links  ^  (Anchor-set  x  Z)estmafi07t-set) 
.1      vixe- ReadLink(lid,  links)  ^  /irf  G  dom  /m^s 

.2     x>ost- ReadLink(lid.  links)(as,  ds)  ^  mk-ZmA:(rnk- Connec^tons^^aa.  </s^,  )  =  links(lid) 
The  Link  Attribute  Operations. 
112.0      type;  AddAttribuie  :  ... 


113.0      type;  RemoveAttribute  :  ... 


114.0      type;  AssignAttribute  :  ... 


115.0      type;  ReadAttribute  :  ... 


A. 2. 3  A  Structural  Class. 
Structure  Operations 

116.0  type;  AddSubstructure  :  SubstructureType  ^  Structure  ^  (Structure  x  Suhsid) 

.1  DTe-AddSubstructureQ  ^  T 

.2  Dost- AddSubstructure(tvpe  ,structure) (structure' ,subsid)  ^ 

.3  let  subsid  G  Subsid  \  dom  structure  in 

.4  structure'  =  structure  U  [s«6sirf  i— > 

.5  mk- Substructure (  Abases  <j/pe  ; 

.6  Set          ^  mk-Setg  >  j. 

.7  Sequence     mk-SeQ(<  >  ), 

.8  Map  mk-Arapf[]^ 

117.0  type;  RemoveSubstructure  :  Subsid  ^  Structure  ^  Structure 

.1  \)Te- RemoveSubstructure(subsid,  structure)  ^  subsid  G  dom  structure 

.2  yost- RemoveSubstructure  (subsid,  structure)  (structure' )  ^  structure'  =  structure  \  {subsid} 


118.0  type;  Having  Destination  :  Destination  ^  Structure  ^  Subsid-set 

.1  pre-HavinQDestinationQ  ^  T 

.2  Dost- HavinQDestination(destination,  structures) (subsids)  ^ 

.3  subsids  —  {swftsirf  |  ('V  subsid  G  dom  structure) 

.4  let  mk- Substucture(substruc,  )  —  structure(subsid)  in 

.5  cases  substruc  : 

.6  Set  -*  destination  G  s, 

.7  Sequence  — ►  destination  G  elems  s, 

.8  Map  -+  destination  G  rng  s^} 


-163- 


119.0  type:  GetSuhstruciureType  :  Suhsid  ^  Structure  ^  SubstructureType 

.1  T>Te-GetSubstructureTvpefsubstd,  structure)  ^  subsid  G  dom  structure 

.2  post- GetSu bstructure Tvpe(subsid, structure) (type)  ^ 
.3  let  mk-Suhstucture(substruc,  )  =  structure(subsid)  m 

A  type  =  /cases  substruc  : 

.5  mk^SetQ  Set. 

'    .6  mk-SegQ  ->■  Sequence, 

.7  mk-Mapf)  ->  Map j 

Set  Operations 

120.0  type;  AddDestinatton  :  (Subsid  x  Destination)  ^  Structure  ^  Structure 

.1  v>xe-AddDestination(subsid,  ,  structure)^ 
.2  subsid  G  dom  structure  A 

.3  let  mk-Substructure(substruc,  )  =  struciures(subsid)  in  'is-Set(substruc) 

A  \>osi- A ddDestination( subsid,  destination,  structure) (structure' )  ^ 
.5  let  mk-Substructure(substruc,  atirs)  =  structure  (subsid)  in 

.6  structure' —  structure  +  [subsid  f-^Tnk-Subsiructure(substrucUi destination] ,attrs)] 

121.0  type;  RemoveDesiinaiion  :  (Subsid  x  Destination)  ^  Structure  ^  Structure 

.1  \)xe-RemoveDestination( subsid,  destination,  structure)  ^ 
.2  subsid  G  dom  structure  A 

.3  let  mk- Substructure  (substruc,  )  —  structures  (subsid)  in 

.4  \s- Set  (substruc)  A  destination  G  substruc 

.5  post- RemoveDestination(subsid. destination, structure) (structure'  )^ 

.6  let  mk- Substructure  (substruc,  attrs)  —  structure  (subsid)  in 

.7  structure' —  structure  +  [subsid  i-ymk- Substructure  (substruc  \  {destination},  attrs)] 

122.0  type;  HavmgDestinationSet  :  (Subsid  x  Destination)  ^  Structure  ^  BOOL 

.1  pre- Having DestinationSet(subsid,  ,  structure)  ^ 
.2  subsid  G  dom  structure  A 

.3  let  mk- Substructure  (substruc,  )  —  structures  (subsid)  in  is- Set(substruc) 

A  x>osi-HavinqDestinationSet( subsid,  destination,  structure) (b)  ^ 

.5  let  mk- Substructure  (substruc,  )  —  structure  (subsid)  in  b  ^  destination  G  substruc 

123.0  type;  GetDestinationSet  :  (Subsid)  ^  Structure  ^  Destination-set 

.1  VTe-GetDestinationSet(subsid,  structure)  ^ 
.2  subsid  G  dom  structure  A 

.3  let  mk- Substructure  (substruc,  )  =  structures(subsid)  in  is- Set(substruc) 

A  yost- GetDestinationSet(subsid,  structure) (ds)  ^ 

.5  let  mk-Substructure(substruc,  )  —  structure(subsid)  in  ds  =  substruc 

124.0  type;  GetCardinality  :  Subsid  ^  Structure  ^  No 

.1  VTe-GetCardinalitv(subsid,  structure)  ^ 
.2  subsid  G  dom  substructure  A 

.3  let  SM^s/rac  —  s-Substruc(substructures(subsid))  in  is-Set(substruc) 

A  post-GetCardinalitv(subsid,  structures) (cd)  ^ 

.5  let  mk- Substructure(substruc.  )  —  structure(subsid)  m  cd  =  card  substruc 


-164- 


Sequence  Operations. 


125.0  type;  InseriDestination  :  (Subsid  x  Destinaiton  x  'No)  ^  Structure  ^  Structure 

.1  ])ve-InsertDestination(subsid,   ,  index,  structure)  ^ 
.2  subsid  G  dom  substructure  A 

.3  let  mk-Substructure(substruc,  )  —  structure  (subsid)  'm 

A  is- Seafsubsiruc)  A  0  <  index  <  [ensubstruc 

.5  x>osi-InsertDesiination(subsid.  destination,  index,  structures)  (structure' )^ 

.6  let  mk-Substructure(subsiruc,  atirs)  —  structure(subsid)  \n 

.7  structure'  =siructure+[subsid  ^-^m]<i-Subsirncture(<substruc\i\\0<i<index>~ 

.8  <destination  >  "  <subsiruc[i\  \  index  <  i  <  ]en  subsiruO,  atirs)] 

126.0  type."  RemoveDesiination  :  (Subsid  x  No)  ^  Structure  ^  Structure 

.1  DTe-RemoveDestination(subsid,  index,  structure)^ 
.2  subsid  G  dom  substructure  A 

.3  let  mk-Subsiructure(substruc,  )  —  structure(subsid)  in 

.4  is-SeQ(substruc)  A  0  <  index  <  \ensubstruc 

.5  yost- RemoveDestinaiion(subsid.  index,  structure) (structure' )  ^ 

.6  let  mk- Substructure  (subsiruc,  attrs)  —  structure  (subsid)  in 

.7  structure'  =siructure+[subsid  > 

.8  mk- Substructure ('<substruc[i]  \  0  <  i  <  index > 

.9  <substruc[i]  |  index  <  i  <  len  substruc>,  atirs)] 

127.0  type;  Having  Destination  :  (Subsid  x  Destination)  ^  Structure  —y  N^-set 

.1  v>re-HavinQDesiinaiion(subsid,  desiinaiion,  structure)  ^ 
.2  subsid  E  dom  substructure  A 

.3  let  mk- Sub  structure  (subsiruc,  )  —  structure  (subsid)  inis- Sea  (subsiruc) 

A  DOst- HavinQDesiinaiion(subsid,  desiinaiion,  structure) (indices)  ^ 

.5  let  mk- Sub  structure  (subsiruc,  )  =  structure  (subsid)  in 

.6  indices  =  {i  \  (i  G  ind  subsiruc) (substruc[i]=  destination)^ 

128.0  type;  GeiDestinaiion  :  (Subsid  x  No)  ^  Structure  ^  Destination 

.1  v>Te-GeiDestinationfsubsid,  index,  siruciure)  ^ 
.2  subsid  G  dom  substructure  A 

.3  let  mk-Subsiruciure(subsiruc,  )  =  siruciure  (subsid)  'm 

A  is^Seq(subsiruc)  A  0  <  index  <  iensubsiruc 

.5  post- GeiDestinaiion f subsid,  index,  siruciure) (desiinaiion)  ^ 

.6  let  mk-Subsiruciure(subsiruc,  )  —  structure  (subsid)  in  destination  =  subsiruc[index] 

129.0  type.-  GeiLength  :  (Subsid)  ^  Structure  ^  No 

.1  pTe-GeiLenaih(subsid,  siruciure)  ^ 
.2  subsid  G  dom  substructure  A 

.3  let  mk- Sub  siruciure  (subsiruc,  )  =  struciure(subsid)  inis- Sep  (subsiruc) 

A  v>ost- GeiLenothfsubsid,  structure) (length)  ^ 

.5  let  mk-Subsiruciure(substruc,  )  =  structures  (subsid)  in  length  =  len  subsiruc 


-165- 


Map  Operations. 


130.0  type;  AddDesiination  :  (Suhstd  x  Name  x  Destination)  ^  Structure  ^  Structure 

.1  TQxe-AddDestinationfsuhsid,  name,  ,  structure)  ^ 

.2  subsid  G  dom  structure  A 

.3  let  mk-Substructurefsubstruc,  )  —  structure(subsid)  in 

A    '  is- Map(substruc)  A  name  ^  dom  suhstruc 

.5  yost- AddDestination(subsid, name,  destination, structure)  (substructure '  )^ 

■6  jet  mk- Sub  structure  (sub  struc,  atirs)  =  structure  (subsid)  in 

131.0  type;  RemoveDesiinaiion  :  (Subsid  x  Name)  ^  Structure  ^  Structure 

.1  pve-RemoveDesiination(subsid,  name,  structure)  ^ 

.2  subsid  6  dom  structure  A 

.3  let  mk-Substructure(substruc,  )  —  structure(subsid)  in 

A  is- Map  (sub  struc)  A  name  G  dom  substruc 

.5  yiost- RemoveDestination(subsid,nam.e, structures)  (structure'  )^ 

.6  let  m\i-Substructure(substruc,  aitrs)  —  structure  (subsid)  in 

.7  structure'  =structure+[subsid  i-+mk- Substructure  (substruc  \  jname},  aitrs)] 

132.0  type;  Having  Destination  :  (Subsid  x  Destination)  ^  Structure  ^  Name-set 

•1  VTe-Havin(iDestination(subsid,  ,  structure)^ 

.2  subsid  £  dom  structure  A 

.3  let  mk-Substructure(substruc,  )  —  structure(subsid)  in  is-Map (substruc) 

.4  i>ost- Havin(iDesiination(subsid,  destination,  structure)  (names)  ^ 

.5  let  mk- Substructure  (substruc,  attrs)  =  structure  (subsid)  in 

.6  names  —  {name  \  (name  £  dom  substruc)  (substruc(name)  —  rfes^maiion^} 


133.0  type."  GetDestinalion  :  (Subsid  x  Name)  ^  Structure  ^  Destination 

.1  \)i(t-GeiDestinaiion(subsid,  name,  structure)^ 
.2  subsid  £  dom  structure  A 

.3  let  mk- Substruciure(substruc,  )  —  siructure(subsid)  in  i§^Map(substruc) 

.4  post- GetDesiinaiion(subsid,  name,  structures)  (destination)  ^ 

.5  let  mk- Sub  structure  (sub  struc,  attrs)  —  structure(subsid)  in  destination  —  substruc(name) 

134.0  type;  GetDomain  :  Subsid  ^  Structure  ^  Name-set 

.1  T)re-GetDomain(subsid,  structure)  ^ 
.2  subsid  £  dom  structure  A 

.3  let  mk- Substructure(substruc,  )  —  structure  (subsid)  in  is- Map  (substruc) 

A  DOst- Get  Do  main  (subsid,  structure)  (ns)  ^ 

.5  let  mk- Substructure  (substruc.  attrs)  —  structure  ( sub  sid)  'm  ns  —  dom  substruc 


The  Structure  Attribute  Operations. 
135.0      type.-  AddAtiribute  :  ... 


136.0      type;  RemoveAttribute  :  ... 


137.0      type:  AssignAttribute  :  ... 


138.0      type;  Read  Attribute  :  ... 


-166- 


A  Multi-Tiered  Approacli  to  Hypertext  Integration: 
Negotiating  Standards  for  a  Heterogeneous  Application  Environment. 


Catherine  C.  Marshall 

Xerox  Palo  Alto  Research  Center 
3333  Coyote  Hill  Road 
Palo  Alto,  California  94304 


Submitted  to  the  NIST  Hypertext  Standardization  Workstiop,  Gaithersburg,  Maryland,  January  16-18, 

1990 

Hypertext  is  most  useful  as  a  technology  when  it  is  embedded  in  an  application:  a  paperless  technical 
manual,  a  notetaker,  a  specification  management  system,  or  any  other  task  domain  where  it  is  useful  to 
represent  and  manipulate  the  structure  of  text.  We  feel  that  it  is  important  to  connect  system 
requirements  for  hypertext  with  the  situation  of  use;  thus  standardization  efforts  should  be  directed  at 
enhancing  the  ability  to  embed  hypertext  in  heterogeneous  applications  environments. 

This  paper  addresses  a  specific  application  and  task  environment  -  using  hypertext  as  a  medium  for  a 
shared  notetaker  that  will  be  used  in  the  intelligence  community  -  and  how  it  suggests  a  protocol-driven 
approach  to  integration.  The  work  described  in  this  paper  includes  an  informal  work  practices  study  of 
the  task  environment,  and  the  development  of  a  functional  specification  for  a  hypertext  system  for 
notetaking. 

From  the  study  and  the  development  of  a  specification,  we  postulate  that  standardization  of  a 
multi-tiered  system  of  linking  protocols  will  help  address  the  closed-world  problem  that  we  have 
encountered  in  NoteCards  and  many  of  the  other  second-generation  hypertext  systems  without 
specifying  rigid  standards  for  applications  that  want  to  share  information  to  a  greater  or  lesser  extent 
with  a  hypertext  substrate.  Such  a  system  of  protocols  can  be  based  in  part  on  existing  work  on 
hypertext  exchange  and  hypertext  reference  models. 

First  we  will  briefly  describe  the  task  environment  and  present  an  informal  model  of  the  task.  Then  we 
will  go  on  to  describe  linking  and  anchoring  requirements  in  support  of  this  task.  Finally,  we  will  argue 
that  a  multi-tiered  system  of  linking  protocols  will  not  only  meet  the  needs  that  we  have  already 
identified,  but  will  be  adaptable  as  the  environment  changes  and  will  facilitate  information  sharing.  It  is 
this  set  of  protocols  that  we  propose  should  be  standardized  based  on  negotiations  between 
applications  developers  and  the  hypertext  community. 


-167- 


An  Informal  model  of  analytic  activities 

The  specification  we  developed  describes  a  hypertext  system  to  support  intelligence  analysts  in  their 
notetaking  and  other  sense-nnaking  activities.  We  based  the  specification  on  requirements  derived 
during  the  course  of  an  informal  work  practices  study  that  we  conducted  at  the  user  site,  coupled  with 
our  previous  understanding  of  the  idea  processing  task  (see  [Halasz  et  al.  1987],  [Trigg  et  al.  1986]  , 
and  [Trigg  et  al.  1987]  for  discussions  of  various  aspects  of  idea  processing  in  NoteCards). 

The  analysts  we  studied  work  in  a  rich,  complex  environment  of  systems  and  information  sources. 
From  these  sources  they  gather  information,  mostly  by  scanning  the  cables  they  receive  through  an 
institutional  mail  system,  or  by  retrieving  information  from  a  variety  of  on-line  resources  (including 
outside  information  services  like  Dialog).  They  read  and  interpret  information  they  gather,  manifesting 
their  interpretation  in  one  of  several  ways.  Sometimes  they  take  notes  on  what  they  read  or  annotate 
the  sources  before  filing  them  in  their  personal  on-line  or  hardcopy  file  systems;  in  other  cases  they 
reflect  their  understanding  of  the  material  by  simply  filing  source  material  or  organizing  it  in  response  to 
a  specific  assignment.  The  product  of  this  interpretation  process  is  usually  either  a  formal  written 
analytic  paper,  or  a  shorter  (and  less  formal)  article. 

Thus,  information  gathering  and  retrieval,  interpreting  sources  through  notetaking  and  filing,  and 
authoring  reports  are  all  important  parts  of  the  analytic  task.  These  processes  interact  in  a  variety  of 
ways:  notetaking  can  be  driven  by  information  gathering,  culling  an  electronic  mail  Inbox,  or  it  can  be 
driven  by  the  production  of  a  written  report.  Retrieval  needs  may  be  refined  in  the  interpretation 
process  as  the  analyst  tries  to  make  sense  of  the  information  at  hand,  or  they  may  be  related  directly  to 
a  specific  assignment.  Structures  to  organize  information  may  also  be  dictated  by  either  sources  or 
products,  or  by  the  internal  models  of  a  domain  that  an  analyst  has  evolved  over  his  or  her  career. 
Finally,  presentations  may  be  prompted  by  analytic  requirements,  or  they  may  be  driven  by  new 
interpretations  that  come  out  of  the  earlier  processes  in  the  flow. 

Furthermore,  we  found  that  the  broader  categories  of  analytic  information  processing  are  collaborative 
or  coordinated  with  people  in  other  organizational  roles.  Interpretation  is  often  collaborative,  sometimes 
involving  telephone  conversations,  or  (less  commonly)  informal  face-to-face  meetings.  Interpretive 
collaboration  is  initiated  by  three  different  types  of  questions:  (1)  "What  do  you  make  of  it?"  (2)  "Do 
you  agree  with  this  (or  can  you  corroborate  this)?"  and  (3)  "What  are  the  implications  of  this?"  If  the 
collaboration  looks  to  be  fruitful,  a  draft-passing  co-authorship  is  negotiated  between  the  two  analysts, 
hence  starting  a  presentation-phase  collaboration.  Coordination  occurs  in  retrieval  tasks  in  two  ways: 
(1)  Some  members  of  the  analytic  work  group  have  specific  expertise  in  retrieval  and  can  help  an 
analyst  gather  information  he  or  she  needs  from  the  institutional  or  outside  sources.  (2)  Some  analysts 
have  specific  resources  (like  their  own  extensive  files);  it  is  a  coordinated  effort  to  locate  the  desired 
information  from  those  files. 


-168- 


Figure  1  sketches  the  flow  between  the  categories  of  analytic  activities  and  shows  how  they  nnay  be 
conducted  in  a  collaborative  setting. 


searching 


interpreting 


presenting 


notetaking 


retrieving 


-i  V  / 
filing 


writing 


coordinated 
retrieval 


collaborative 
interpretation 


draft- 
passing 


review  cycle 
coordination 


Figure  1 .  Analytic  information  processing  activities 


In  order  to  determine  requirements  for  hypertext  in  the  context  of  this  task  environment,  it  is  important 
to  investigate  three  areas:  (1)  where  the  information  comes  from;  (2)  the  relationship  between  the  kinds 
of  notes  analysts  take  and  the  information  sources;  and  (3)  what  use  the  information  is  put  to  after  the 
interpretation  is  complete.  From  looking  at  (1)  and  (3),  we  will  be  able  to  determine  a  strategy  for 
integrating  hypertext  into  an  applications  environment,  and  from  (2),  we  will  understand  requirements  on 
linking  pieces  of  information  together. 

Where  information  comes  from.  The  analysts  we  studied  use  a  variety  of  sources,  some  currently 
available  on-line  or  destined  to  be  on-line  in  the  foreseeable  future,  and  others  that  will  continue  to  be 
available  only  in  hardcopy  forms.  Frequently  cited  anecdotal  evidence  suggests  that  only  five  percent 
or  so  of  the  available  data  is  ever  used  in  analysis;  therefore,  analysts  all  feel  very  strongly  about  pulling 
in  material  from  a  variety  of  sources  and  processing  as  much  of  it  as  possible.  It  is  a  widely  held  belief 
in  the  intelligence  community  that  contradictory  analytic  results  stem  from  the  use  of  different  sources, 
rather  than  from  different  interpretations  of  the  same  facts. 

We  have  categorized  the  sources  of  on-line  information  that  analysts  use  into  four  groups:  personal  files 
and  databases,  information  from  systems  maintained  by  the  analyst's  working  group,  information  from 
institutional  databases  and  mail  systems,  and  information  maintained  external  to  the  organization  such 
as  open  literature  databases.  These  catagories  suggest  that  there  are  varying  degrees  of  control  that 
hypertext  developers  will  have  over  the  systems  and  databases  supplying  this  information.  At  best  -  as 
in  the  case  of  personal  files  and  working  group  databases  -  the  hypertext  substrate  will  be  able  to 


-169- 


represent  and  display  the  information  at  both  ends  of  a  link;  at  worst  -  the  cases  where  connmercial 
information  sources  are  used  -  the  hypertext  substrate  will  only  be  able  to  represent  a  method  for 
initiating  the  outside  application. 

In  our  study,  the  most  important  source  of  day-to-day  on-line  information  is  the  institutional  mail  system 
that  supplies  each  analyst  with  cable  traffic,  filtered  by  an  interest  profile.  Each  analyst  described  a 
process  of  going  through  the  day's  institutional  mail  in  a  linear  sequence  and  deciding  which  messages 
are  of  interest.  Currently,  these  messages  are  hardcopied  for  further  processing,  mainly  highlighting 
and  otherwise  marking  them  up.  Therefore,  the  most  prevalent  example  of  where  the  information 
comes  from  falls  between  the  two  extremes. 

How  notes  are  related  to  sources.  The  analysts  we  studied  exhibited  a  range  of  notetaking  styles. 
Many  of  them  relied  strictly  on  annotative  notes;  that  is,  they  would  make  hardcopies  of  source 
materials,  and  mark  up  the  pages.  Annotative  notes  are  taken  in  two  different  ways.  Often,  a 
broad-tipped  highlighting  pen  is  used  to  go  over  words,  sentences,  or  paragraphs  of  particular  interest. 
Some  analysts  have  a  preference  for  specific  colors  when  they  are  doing  this  type  of  highlighting 
annotation.  The  second  annotative  style  of  notetaking  involves  writing  short  notes  in  the  margins  of  the 
hardcopy.  For  example,  one  of  the  analysts  marked  things  he  did  not  believe  to  be  true,  or  that  he 
found  anomolous;  he  noted  those  beliefs  in  the  margins.  Annotative  notes  are  closely  bound  to 
selected  segments  of  text;  in  hypertext  terms,  they  reiy  on  access  to  a  portion  of  the  content  of  a  node. 

We  found  that  the  analysts  also  use  interpretive  notes  to  record  hypotheses,  conclusions  they  have 
reached,  or  material  they  have  integrated  from  several  sources.  These  notes  are  frequently  taken 
on-line  in  the  text  editor;  sometimes  this  style  of  notetaking  involves  a  significant  amount  of  retyping  to 
associate  notes  with  their  sources.  Analysts  also  take  interpretive  notes  that  do  not  refer  directly  to  any 
source,  or  that  refer  to  a  computational  model.  Interpretive  notes  are  less  tightly  bound  to  individual 
words  or  sentences  in  a  document.  More  often,  they  refer  to  a  general  assimilation  of  the  document's 
content.  Thus  they  frequently  point  to  what  would  be  represented  in  hypertext  as  a  node. 

All  of  the  analysts  in  our  study  made  some  use  of  reminding  notes,  Post-its  or  other  jottings  on  paper 
that  serve  to  jog  their  memory  about  things  to  do  (an  agenda  of  subtasks)  or  portions  of  procedures  to 
follow  (for  example,  how  to  log  on  to  a  given  outside  data  service,  or  how  to  retrieve  a  piece  of 
information).  Reminding  notes  may  be  an  important  way  of  preserving  procedural  knowledge.  These 
notes  often  do  not  refer  directly  to  a  node  or  its  content,  but  rather  how  to  get  to  it;  they  can  be  thought 
of  as  referring  to  the  link. 

Figure  2  summarizes  the  three  categories  of  notetaking  styles  we  observed  in  the  work  group. 


-170- 


Highlighting  of  text  and 
keywords 

Interpretive  or  integrative 
notes  referring  to  one  or 
more  sources 

Auxiliary  notes 
documenting  a  systematic 
process 

nl  II  lUicl  tl         1  BLllc^o 

Interpretive  notes 

Reminding  notes 

Annotations  and 
comments  in  the  margins 

Text  notes  not  referring  to 
any  source  directly 

Auxiliary  notes  listing  an 
agenda  of  subtasks 

Figure  2.  Analysis  of  notetaking  styles 


How  information  is  used.  Information  is  used  two  ways:  analysts  build  up  personal  files  and  they 
write  analytic  reports  and  short  articles,  artifacts  recognized  by  the  community.  This  paper  will  not 
discuss  our  findings  about  how  notes  and  collected  information  are  filed.  Instead  we  will  focus  on  the 
use  of  information  in  analytic  products,  since  one  analyst's  filing  structure  is  usually  opaque  to  the  other 
analysts.  It  is  difficult  for  analysts  to  retrieve  information  from  one  another's  files,  and  once  an  analyst 
leaves  the  organization,  his  or  her  files  quickly  deteriorate  in  value.  Thus,  in  order  to  make  the 
information  useful  to  anyone  else,  the  analyst  must  either  document  this  structure  or  publish  any 
interesting  analytic  results. 

Two  kinds  of  analytic  products  are  supported  by  the  institutional  system,  formal  publications  and  shorter 
articles.  These  analytic  products  are  created  by  integrating  on-line  sources  and  notes,  and  collections 
of  annotated  hardcopy  material.  Most  of  the  analysts  pull  out  their  collection  of  materials  on  the  desired 
subject  to  create  a  context  for  writing  and  to  maintain  traceability,  which  is  universally  cited  as  an 
important  requirement  on  (and  role  for)  hypertext.    In  all  cases,  the  publication  of  an  analytic  product, 
and  the  subsequent  usefulness  of  the  document  or  article  is  directly  related  to  the  ability  to,  in  hypertext 
terms,  follow  its  links  back  to  the  sources. 

Once  an  analytic  product  has  gone  through  the  coordination  cycle,  it  may  be  used  by  low  level 
policy-makers,  by  various  staff  members,  and  by  other  analysts  (sometimes  affiliated  with  different 
agencies).  Analysts  expressed  a  desire  for  a  "lighter  weight"  analytic  product  in  order  to  share  smaller 
chunks  of  analytic  results  with  their  community  and  receive  credit  for  coming  up  with  these  results;  in 
hypertext  terms,  we  might  think  of  this  as  sharing  an  interpretive  layer  over  a  heterogeneous  collection 
of  databases. 

Linking  and  anchoring  to  support  of  notetaking 

From  our  observations  about  notetaking  in  the  analytic  process,  we  have  derived  a  set  of  requirements 
on  links,  how  they  are  anchored,  and  what  this  implies  about  an  integration  strategy. 


-171- 


Links  are  named,  typed,  and  have  direction .    Because  we  expect  a  variety  of  relationships  between 
nodes  (for  example,  an  analyst  might  want  to  specify  relationships  like  source,  supports,  or  refutes), 
links  must  be  named.  Furthermore,  since  we  expect  links  to  have  different  characteristics,  links  must 
have  types,  so  that  a  behavior  can  be  associated  with  the  named  link.  In  NoteCards,  we  have  found 
that  the  ability  to  specify  the  directionality  of  a  relationship  to  be  somewhat  difficult  for  users;  however, 
we  still  feel  that  representation  of  the  direction  of  a  link  may  be  useful  for  expressing  dependencies. 

Links  are  n-ary.  For  a  hypertext  notetaker,  n-ary  links  are  important  for  representing  the  relationships 
implied  by  what  we  have  called  interpretive  notes.  An  interpretive  note  can  integrate  or  synthesize  the 
information  in  more  than  one  source;  hence,  the  link  from  the  note  to  the  source  would  require  multiple 
endpoints  to  accurately  represent  what  is  going  on  in  the  notetaking  process.  Figure  3  illustrates  an 
n-ary  link  example.  In  this  example.  Note  #1  integrates  material  from  the  highlighted  portion  of  Source 
A  and  Source  B. 


Source  A 


Figure  3.  Example  of  how  n-ary  links  may  be  used  in  the  notetaker 

Links  can  either  connect  nodes  or  refer  to  nodes.  There  are  two  different  notions  of  linking  in 
hypermedia  systems.  Reference  links  are  components  within  a  node  that  contain  a  name  or  address 
that  refers  to  another  node  (or  a  region  within  another  node),  or  a  procedure  for  retrieving  that  node; 
thus  a  link's  destination  can  be  computed  at  traversal.  Reference  linking  is  important  in  the  case  where 
an  analyst  is  performing  a  query  to  an  external  database  and  wants  dynamically  computed  results. 

Connection  links  are  components  that  connects  a  node  or  region  within  a  node  with  another  node  or  a 
region  within  it;  the  objects  at  both  ends  of  the  link  "know"  about  the  link.  For  the  purposes  of  the 
notetaker,  connections  will  provide  a  stronger  tie  between  the  information  at  the  source  and  the 
annotative  or  interpretive  note  at  the  other  end  oi  the  link. 

Links  can  be  anchored  In  a  span  of  text.  A  link  anchor  is  the  span  within  a  node  corresponding  to  the 
endpoint  of  a  link.  In  some  hypermedia  systems  the  span  may  be  limited  to  a  single  point  (eg. 


-172- 


NoteCards  [Halasz  et  al.  1987])  or  to  the  entire  node  (eg.  gIBIS  [Conklin  &  Begennan  19881).  Other 
anchoring  schennes  (eg.  Intermedia  [Garrett  et  al.  1986])  may  allow  anchors  to  encompass  arbitrary 
extents  of  text  (or  graphics)  within  a  node. 

Analysts'  notetaking  practices  suggest  a  need  for  "span-to-span"  links,  where  an  arbitrary  region  or 
collection  of  objects  can  be  connected  with  another  arbitrary  region  or  collection  of  objects  as  illustrated 
in  Figure  4.  Span-to-span  linking  is  important  to  the  notetaker  because  most  source-connected  notes 
that  analysts  take  generally  refer  to  a  region  of  text.  Furthermore,  it  is  important  to  identify  which  parts 
of  a  multi-source  note  or  a  document  refer  to  which  sources. 


MoteCards  has  point-to-node  links. 


Figure  4.  Span-to-span  linking 

More  specifically,  span-to-span  linking  supports  the  kind  of  annotative  notetaking  that  we  have 
observed.  The  anchoring  and  marking  process  is  similar  to  the  highlighting  that  analysts  use  to  set 
apart  a  region  of  text.  In  this  case,  it  is  the  delimiting  of  text  that  is  important;  a  special  link  type  can 
support  this  span-to-null  link.  The  ability  to  include  marginalia  as  annotations  depends  on  using  a 
span-to-node  or  span-to-span  link.  See  [Catlin  et  al.  1989]  for  an  example  of  how  span-to-span  linking 
can  support  annotation. 

Links  are  marked  to  reflect  their  properties.  Link  markers  are  the  method  by  which  the  system 
indicates  the  presence  of  a  link  anchor  to  the  user.  What  information  a  link  marker  displays  should 
reflect  its  function.  Link  markers  in  the  notetaker  should  allow  an  analyst  to  detect  the  presence  of  a 
link  without  requiring  extra  action  (as  an  annotation  can  be  detected),  distinguish  the  level  of  integration 
of  the  link's  destination,  and  determine  the  scope  of  the  anchor's  span  (as  highlighting  shows  scope). 

Links  can  be  annotated.  Because  procedural  or  reminding  notes  sometimes  refer  to  links,  rather  than 
to  nodes,  links  should  have  the  ability  to  be  annotated.  In  the  case  of  very  shallow  linking  (where  the 


-173- 


actual  reference  is  not  sufficient  to  resolve  what  should  be  at  the  other  end  of  the  link),  link  annotation 
can  supplement  automated  link  resolving  mechanisms. 

Levels  of  integration 

This  set  of  requirements  on  links,  coupled  with  the  analysts'  need  to  trace  notes  and  finished 
intelligence  back  to  its  sources  and  their  use  of  a  variety  of  tools  in  the  sense-making  process,  leads  us 
to  a  multi-tiered  integration  scheme.  Of  the  different  tools  and  applications  available  in  the  analysts' 
environment,  some  will  be  more  amenable  to  deep  integration  than  others.  Furthermore,  we  have  found 
that  the  various  kinds  of  notes  that  analysts  take  require  greater  or  lesser  connection  to  outside 
information,  and  that  in  some  situations,  the  payoff  for  deeper  integration  is  large,  while  in  others, 
shallow  integration  is  all  that  is  necessary. 

We  have  divided  integration  into  three  levels,  listed  in  order  of  depth:  (1)  data  or  content  based 
integration;  (2)  tool  or  node  based  integration;  and  (3)  display  or  window  based  integration.  This  list 
suggests  a  need  for  three  protocols,  which  we  feel  are  general  to  embedding  hypertext  in  a 
heterogeneous  application  environment:  an  anchoring  protocol,  a  linking  protocol,  and  a  launching 
protocol.  Figure  5  summarizes  the  relationship  between  the  protocols  and  the  depth  of  integration. 


DEPTH 

PROTOCOLS 

anchoring 

linking 

launching 

data/ 
content 

m 

tool' 
node 

display/ 
window 

Figure  5.  Relationship  between  protocols  and  depth  of  integration 

At  the  deepest  level,  integration  requires  access  to  the  content  of  a  node.  Integration  at  this  level 
implies  that  applications  must  obey  an  anchoring  protocol  to  describe  the  extent  of  the  anchor  within  the 
node,  a  linking  protocol  to  retrieve  nodes  from  applications  outside  the  notetaker,  and  a  display  protocol 
so  the  notetaker  can  present  the  node  in  a  suitable  window.  Deep  integration  makes  it  possible  to  treat 
information  from  outside  the  hypertext  system  the  same  way  as  it  is  treated  within  the  system;  thus 
traversing  in  a  link  is  the  same  as  it  would  be  were  the  node  maintained  by  the  notetaker. 

At  the  next  level  of  integration,  linking  is  supported  so  nodes  of  information  from  other  applications  can 
be  included;  in  this  case,  the  application  only  needs  to  implement  the  linking  and  display  protocols.  In 
this  case,  traversing  a  link  is  a  retrieval  of  a  piece  of  information  outside  the  notetaker. 


-174- 


Display-based  integration  is  the  most  superficial  of  the  three  levels.  The  purpose  of  display-based 
integration  is  to  provide  access  to  outside  tools;  at  this  superficial  level  of  integration,  traversing  a  link  is 
a  launch  of  an  application  in  a  window. 

Figure  6  shows  a  hypothetical  notetaking  situation,  where  an  analyst  has  taken  a  note  referring  to  three 
outside  sources,  one  at  each  level  of  integration.  The  first  text  span  of  the  note  is  integrative,  and 
refers  to  the  first  two  outside  nodes;  protocols  tell  the  notetaker  how  to  launch  each  application  and 
retrieve  the  appropriate  node.  Because  the  node  fronn  the  first  application  supports  anchoring,  the 
extent  of  the  anchor's  span  is  also  marked.  The  note's  second  span  of  text  refers  to  the  entirety  a 
node  in  the  second  application;  linking  is  supported,  but  anchoring  is  not,  so  only  the  node  can  be 
retrieved  and  displayed.  The  third  span  of  text  in  the  notetaker's  node  refers  to  some  portion  of  the 
application  launched  in  the  third  window.  Since  neither  linking  nor  launching  is  supported,  the 
application  can  only  be  brought  up  in  a  window.  The  annotation  on  the  third  link  object  is  the  user's 
procedural  note  describing  how  to  get  the  proper  information  from  the  third  application. 


Outside  sources 


Node  from 
application  #1 
that  supports 
anchoring 
protocol 


Node  from 
application  #2 
that  supports 
linking  protocol 


Window  from 
application  #3 
that  supports 
launching 
protocol 


N'l'iViViViViVi'i'i'i  iV  I  I't'iVi'i'iVA 


Link  objects 


launch  application 
^Ink  destination 
anchor  span 

link  source 
anchor  span-^ 

launch  application 
Jink  destination 


no  anchor 


launch  application 
link  destination 
no  anchor 


link  source 
anchor  span 


launch  application 
no  link 


no  anchor 


link  source, 
anchor  span 


annotation 


Note  (node) 
maintained  by 
notetaker 


Figure  6.  Hypothetical  notetaking  situation  contrasting  levels  of  integration 


Defining  the  three  levels  of  protocol  will  allow  the  launching,  linking,  and  anchoring  specifications  to  be 
expressed  and  stored  in  the  link  objects,  and  understood  by  the  outside  applications  to  the  degree  that 
they  support  the  protocols. 


-175- 


Conclusion 


In  this  paper,  we  argue  that  standardization  efforts  should  not  only  be  concerned  with  a  hypertext 
reference  model,  but  also  a  multi-tiered  system  of  protocols  for  integrating  information  from  a 
heterogeneous  applications  environment.  We  make  this  argument  using  evidence  from  a  study  of  a 
sense-making  activity,  taking  notes  in  the  performance  of  an  intelligence  analysis  task;  we  feel  that  this 
activity  is  representative  of  a  wider  class  of  idea  processing  tasks,  and  that  the  applications  environment 
shares  many  characteristics  with  other  environments  where  hypertext  will  provide  particular  leverage  on 
work  involving  representing  and  manipulating  the  structure  of  text. 

The  study  we  have  performed  shows  that  the  closed-world  assumption  at  the  root  of  many 
second-generation  hypertext  systems  limits  the  ultimate  usefulness  of  those  systems,  and  that  future 
hypertext  work  must  consider  at  least  partially  open  architectures.  Thus  creating  standards  for 
hypertext  necessarily  includes  developing  protocols  for  integration  of  outside  applications.  Our  results 
suggest  that  three  levels  of  protocols  will  be  useful,  an  anchoring  protocol,  a  linking  protocol,  and  a 
launching  protocol.  These  protocols  can  be  closely  tied  to  the  reference  model  adopted  by  the 
hypertext  community  (see  [Halasz  &  Schwartz  1989])  to  ensure  a  common  description  of  what  is 
included  in  each  protocol. 

Acknowledgements 

I'd  like  to  thank  Frank  Halasz  for  some  helpful  discussions  during  the  development  of  the  notetaker 
specification. 

References 

[Catlin  et  al.  1989]  Catlin,  T.,  Bush,  P.,  and  Yankelovich,  N.,  "InterNote:  Extending  a  Hypermedia 
Framework  to  Support  Annotative  Collaboration,"  Proceedings  of  Hypertext  '89,  Pittsburgh, 
Pennsylvania,  November  5-8,  1989,  pp.  365-378. 

[Conklin  &  Begeman  1988]  Conklin,  J.  &  Begeman,  M.,  "gIBIS:  A  Hypertext  Tool  for  Exploratory  Policy 
Discussion,"  ACM  Transactions  On  Office  Information  Systems  Vol.  6,  No.  4,  October,  1988,  pp. 
303-331. 

[Garrett  et  al.  1986]  Garrett,  L.N.,  Smith,  K.E.,  and  Meyrowitz,  N.,  "Intermedia:  Issues,  strategies,  and 
tactics  in  the  design  of  a  hypermedia  document  system,"  Proceedings  of  the  Conference  on 
Computer- Supported  Cooperative  Work,  Austin,  Texas,  December  3-5,  1986,  pp  163-174. 

[Halasz  et  al.  1987]  Halasz,  F.  G.,  Moran,  T.  P.,  Trigg,  R.  H.,  "Notecards  in  a  Nutshell,"  Proceedings 
of  the  /ACM  CHI  +  GI  Conference,  pp.  45-52,  Toronto,  1987. 

[Halasz  1988]  Halasz,  F.G.  "Reflections  on  NoteCards:  Seven  Issues  for  the  Next  Generation  of 
Hypermedia  Systems,"  Communications  of  the  ACM,  Vol.  31,  No.  7,  July  1988,  p.  836-852. 

[Halasz  &  Schwartz  1989]  Halasz,  F.G.  &  Schwartz,  M.,  "A  Reference  Model  for  Hypertext,"  Submitted 
to  the  Hypertext  Standardization  Workshop,  Gaithersburg,  Maryland,  January  16-18,  1990. 


-176- 


[Trigg  et  al.  1986]  Trigg,  R.  H.,  Suchman,  L.,  Halasz,  F.  G.,  "Supporting  Collaboration  in  NoteCards," 
Proc.  of  Conference  on  Computer  Supported  Cooperative  Work,  Austin,  Texas,  December  3-5,  1986, 
pp  153-162. 

[Trigg  et  al.  1987]  Trigg,  R.  H.,  Moran,  T.  P.,  Halasz,  F.  G.,  "Adaptability  and  Tailorability  in 
NoteCards,"  Human-Computer  Interaction  -  INTERACT  '87,  H.-J.  Bullinger  &  B.  Shackel  (Eds.),  Elsevier 
Science  Publishers  B.V.  (North-Holland),  1987. 


-177- 


10.  Newcomb,  Steven  R.  -  Explanatory  Cover  Material  for  Section  7.2  ofX3V1.8M/SD-7 
Explanatory  Cover  Material  for  Section  7.2  of  X3V1.8M/SD-7,  Fifth  Draft. 

Steven  R.  Newcomb, 
Vice  Chairman,  X3V1.8M,  and 
Associate  Director,  Center  for  Music  Research,  Florida  State  University 

The  mission  of  the  ANSI  X3V1.8M  Music  in  Information  Processing  Standards  (MIPS) 
committee  is  to  develop  a  Standard  Music  Description  Language  (SMDL)  to  enable 
interchange  of  musical  documents.  The  committee  has  chosen  to  represent  the  structure 
of  the  information  represented  by  SMDL  as  a  Standard  Generalized  Markup  Language 
(ISO  8879-1986)  Document  Type  Definition  (an  "SGML  DTD"). 

In  the  course  of  its  work  (which  began  in  1986),  the  MIPS  committee  developed  a 
general  model  for  the  representation  of  schedules  for  the  execution  of  events.  WTien  it 
confronted  the  problem  of  representing  music  in  several  of  its  normal  contexts,  such  as 
the  interdependently  synchronized  lighting,  staging,  and  orchestra  cues  in  musical 
comedy  and  opera,  the  MIPS  committee  developed  SGML-based  means  of  representing 
links  within  and  among  documents.  These  means  are  what  is  set  forth  in  the  following 
extract  (Section  7.2  ["General  Links"]  of  the  fifth  draft  of  X3V1.8M/SD-7 
["Hypermedia/Time-based  Document  Subset"]. 

When  it  became  clear  that  this  model  would  be  useful  for  the  representation  of  the 
scheduling  of  non-musical  (as  well  as  musical)  events  multimedia  and  hypermedia 
documents,  the  committee  extracted  the  time  model  from  the  other,  strictly  music-related 
portions  of  SMDL,  gave  the  model  a  name  ("HyTime"),  and  placed  it  in  its  own  Standing 
Document,  X3V1.8M/SD-7.  In  the  current  draft  of  SMDL,  Standard  Music  Description 
Language  (SMDL)  is  an  application  of  HyTime.  (The  rest  of  SMDL  is  described  in 
X3V1.8M/SD-8.) 

When  HyTime 's  "General  Links"  facilities  were  discussed  at  the  NIST  Hypertext 
Workshop,  it  tumed  out  that  the  Dexter,  Intermedia,  and  HyTime  models  all  decomposed 
the  problem  of  document  addressing  in  much  the  same  way,  although  their  jargon  was 
dissimilar.  The  "Room  705  Ad  Hoc  Group"  (Ed  Fox,  Steve  Newcomb,  Tim  Oren,  and 
Victor  Riley)  succeeded  in  showing  how  the  "anchor"  concept  in  the  three  models  could 
be  merged.  It  is  anticipated  that  the  NIST  Hypertext  Workshop  will  have  significant 
impact  on  succeeding  drafts  of  HyTime. 


-179- 


X3V1.8M/SD-7 


X3V1.8M/SD-7  Fifth  Draft 


August  11,  1989 

X3V1.8M/SD-7  Journal  of  Development 

Standard  Music  Description  Language  (SMDL) 

Part  Two:  Hypermedia/Time-based  Document  Subset  (HyTime) 

EDITORS: 

Charles  F.  Goldfarb,  IBM  Almaden  Research  Laboratory 
Alan  D.  Talbot,  New  England  Digital  Corporation 


Includes  work  as  of  June  22.  1989.  Effective  through  October  31,  1989 


7.2    General  Links 

General  links  are  relationships  between  documents  or  parts  of  documents.    The  set  of 

potential  general  links  is  infinite,  so  the  mechanisms  provided  by  HyTime  are  extensible  by 
users  and  applications. 


Note:  The  term  "general  link  "  is  used  in  preference  to  the  unqualified  term  "link"  to 
avoid  confusion  with  the  SGML  link  feature.  However,  there  is  no  problem  in  using 
"link"  with  more  restrictive  qualifying  adjectives,  as  in  "hypertext  link,"  or  with  no 
qualifiers  when  the  context  is  clear. 

Some  forms  of  general  link  occur  in  all  documents,  not  jusi  those  intended  for  hypertext  and 
hypermedia  access.  Those  forms  are  represented  by  inherent  SGML  functions,  so  HyTime 
does  not  need  to  address  them. 

Note:   Some  examples  are: 

—  Links  that  associate  a  semantic  role  (such  as  "paragraph"  or  "heading")  with  an 
element  are  represented  in  SGML  by  generic  identifiers. 

-■  Other  links  that  associate  a  property  with  an  element  (rather  than  associating  two 
elements  with  one  another)  are  usually  represented  in  SGML  by  attributes. 

Note:  (""EDITOR")  We  may  want  a  specialized  link  element  nonetheless, 
for  those  cases  in  which  the  document  cannot  be  modified  to  add  an 
attribute. 


-180- 


X3V1.8M/SD=7  Fifth  Draft 


—  Links  that  specify  layout  or  typography,  or  other  processing  of  a  document,  are 
represented  by  the  SGML  link  feature. 

—  Links  between  the  logical  structure  of  the  document  and  physical  storage  are 
expressed  by  the  SGML  entity  mechanism,  which  includes  the  ability  for  a  user  to 
segment  and  link  a  document  physically  on  whatever  boundaries  he  requires. 

The  following  forms  of  general  link  are  supported  by  HyTime.  either  via  inherent  SGML 
mechanisms,  or  by  elements  and  attributes  defined  in  this  Standard.  (The  list  is  derived 
from  "A  Tentative  Listing  of  Some  Linktypes"  on  pp.4/52-4/55  of  Ted  Nelson's  Literary 
Machines,  Edition  87.1) 

Note:  ("EDITOR")  This  list  represents  one  view  of  the  requirements  for  general  link 
support,  and  as  such  provides  an  initial  touchstone  against  which  to  evaluate  the 
language  design.  It  is  provided  merely  as  a  starting  point,  and  it  is  expected  that 
others  will  suggest  additions  and  modifications  to  both  the  list  and  the  design. 

a)  metalinks 

title 
author 

author  (external  claim) 
document  supersession  link 

b)  ordinary  text  links  for  sequential  documents 

correction  link 
comment  link 
counterpart  link 
translation  link 
heading  link 
paragraph  link 
inclusion 

quote-link  (annotated  inclusion) 
layout,  typography,  epigraphy  links 
footnote  link 

c)  hypertext  links 

vanilla  jump-link 
modal  jump-iinks 
suggested-threading  links 
expansion  links 

d)  literary  links 

citation  link 
alternative-version  link 
comment  document 
certification  links 
mail  link 

Links  can  also  solve  the  unique  structural  problems  of  interactive  multimedia  documents, 
such  as  instructional  materials.  For  example,  when  the  normal  sequence  of  elements  is 
interrupted  by  a  user  response,  links  in  audio  material  could  indicate  suitable  jumps  to 
graceful  endings. 

In  HyTime,  general  links  all  consist  of  one  or  more  "link  ends"  (Nelson  calls  them  "end 
sets"),  together  with  a  description  of  the  purpose  of  the  link  (the  "link  type").  A  general  link 
also  has  an  associated  "link  term"  that  an  application  displays  as  a  "button"  from  which  the 
link  can  be  accessed.  In  character  text,  the  link  term  is  a  word  or  phrase  that  is  the  subject 
of  the  link,  and  the  "button"  is  usually  the  link  term  in  a  highlighted  font.  In  other  data,  the 
link  term  is  a  location  (for  example,  a  coordinate  in  a  displayed  image),  and  the  button  might 
be  a  cursor  that  changes  shape  when  it  is  over  the  link  term  location. 

Note:    ("EDITOR")  Do  we  need  the  potential  for  a  link  term  at  each  link  end? 

HyTime  includes  four  element  types  that  represent  general  links: 


-181- 


X3V1.8M/SD.7  Hfth  Draft 


—  The  independent  link  is  the  most  flexible.  It  can  have  any  number  of  link  ends  and  they 
can  be  in  any  documents,  even  those  to  which  there  is  no  write  access. 

—  The  contextual  link  has  oniy  two  link  ends,  one  of  which  is  at  the  location  of  the 
contextual  link  element. 

—  The  excerpt  is  a  special  form  of  contextual  link  that  is  used  for  including  portions  of  other 
documents,  with  or  without  acknowledgment. 

—  The  location  reference  is  a  special  form  of  contextual  link  that  is  used  for  automatic 

cross-referencing  within  a  document. 


7.2.1    Sudependant  Link 

The  element  independent  i'mk  (ilink)  represents  a  general  link  whose  link  ends  are 
independent  of  the  ilink  element  itself.  The  content  of  the  iiink  element,  if  present,  is  the  link 
term. 

An  independent  link  occurs,  as  its  name  implies,  out  of  the  normal  context  of  the  document. 
Its  location  need  have  no  connection  with  the  location  of  its  link  ends. 

Note:  An  iiink  can  be  used  in  situations  where  it  is  not  possible  to  modify  the  link 
end  locations.  If  one  of  the  link  ends  can  be  modified,  it  may  be  more  convenient  to 
use  a  contextual  link  (see  7.2.2). 

The  attribute  iinkends  {link  ends)  identifies  one  or  more  locations  that  are  the  subject  of  the 
link.  Each  can  be  a  document  location,  data  entity  location,  or  some  other  element, 
including  another  general  link.  The  number  of  link  ends,  and  their  meaning,  are  a  function 
of  the  link  type,  which  is  determined  by  the  application. 

The  attribute  Iwdepersdentt  JSnk.typ®  {ilinktyp)  identifies  the  purpose  of  the  link.  The  possible 
values  are  determined  by  the  application. 

Note:  Uses  for  independent  links  include  comments  and  notes  by  reviewers  and 
collaborative  authors,  external  thesauri  and  indexes,  and  identification  of  various 
kinds  of  alternative  versions. 

The  attribute  link  term  (linkterm)  identifies  the  link  term  of  the  link.  If  not  specified,  the 
content  of  the  ilink  element  is  the  link  term. 

The  entity  a.ilink  allows  additional  attributes  to  be  defined. 


<!—  7.2.1    Independent  Link  — > 
<! ELEMENT  ilink      —  Independent  link:  independent  of  its  location  (included) 
-  0    ANY  » 

<i£NTITY  %  a.ilink  «  «  —  User-defined  independent  link  attributes  > 
<!ATTLIST  ilink      id  — ■  Used  when  this  ilink  is  linked  to  — 

ID  ^IMPLIED 
linkends  —  Ends  of  link:  element,  docloc,  or  entloc  — 

IDREFS  #REQUIREO 
ilinktyp  —  Purpose  of  link  (application-defined)  — 
COATA      flMPLIED       Default:  implied  by  GI 
linktenw  —  Index  term  or  "button^  location  — 

IDREF      ^COMREF     —  Oe fault r  content  of  ilink  — 
%a. ilink;  > 


X3V1.8M/SD-7  Fifth  Draft 


7.2.2    Contextual  Link 

The  element  contextual  Vmk  {clink)  represents  a  general  link  with  two  link  ends.  One  of  the 
link  ends  is  the  content  of  the  contextual  link  element,  which  must  be  valid  in  the  context  in 
which  the  clink  element  occurs.  The  content  can  be  entity  if  the  link  end  is  simply  a  point  in 
the  text,  rather  than  a  span  of  a  character  string. 

A  contextual  link  occurs,  as  its  name  implies,  in  context  at  exactly  the  location  of  one  link 
end.  The  content  of  the  contextual  link  element,  if  it  is  not  empty,  is  the  link  term  as  well  as 
a  link  end.  It  is  also  treated  as  part  of  the  content  of  the  containing  element,  just  as  if  there 
were  no  dink  tags  around  it. 

Mote:  A  clink  can  be  used  only  if  the  link  has  only  two  ends  and  one  of  them  can  be 
modified  to  incorporate  the  clink  tags.   In  other  cases,  the  independent  link  can  be 

used  (see  7.2.1). 

The  attribute  linkend  {link  end)  identifies  the  other  end  of  the  link.  It  can  be  a  document 
location,  data  entity  location,  or  some  other  element,  including  another  general  link.  The 
meaning  of  the  link  end  is  a  function  of  the  link  type,  which  is  determined  by  the  application. 

The  attribute  contextual  link  type  {dinktyp)  identifies  the  purpose  of  the  link.  The  possible 
values  are  determined  by  the  application. 

Note:    Uses  for  contextual  links  include  various  forms  of  hypertext  links  and 
alternative  access  paths  through  a  document. 

The  attribute  automat!c  mtum  {return)  indicates  whether  processing  of  the  document  returns 
automatically  to  the  end  of  the  ciink  after  processing  the  link  end. 

The  entity  a.cUnk  ailows  additional  attributes  to  be  defined. 


<!—  7.2.2   Contextual  Link  — > 
<! ELEMENT  clink      —  Contextual  link:  nested  subelement  of  Its  parent  — 
-  0   ANY  > 

<!ENTITY  %  a. ciink  "  "  —  User-defined  contextual  link  attributes  > 
<!ArTLISTc1ink      id  —  Used  when  this  clink  is  linked  to  — 

10  ^IMPLIED 
linkend    —  Other  end  of  link:  element,  docloc,  or  entloc 

IDREF  *?REqUIRED 
clinktyp  -»  Purpose  of  link  (application-defined)  -- 

COATA  #REQUIRED 
return         Automatic  return  at  end  of  linkto  element  — 

(return  I noreturn)  roreturn 
%a. clink;  > 


7.2.3  ExcerpS 

The  SGML  external  entity  reference  is  the  normal  vehicle  for  including  text  from  one 

document  within  another.  Such  inclusion  is  transparent,  in  the  sense  that  if  the  included 
material  is  itself  represented  ini  SGML,  an  SGML  parser  will  deal  with  it  without  advising  the 
application  program.  Therefore,  iff  an  application  wishes  to  acknowledge  that  certain 
materia!  is  included  from  other  documents,  an  additional  construct  is  required. 

The  element  ascerpi  {excerpt)  is  a  type  of  contextual  link  that  identifies  a  portion  of  another 
document  (the  "excerpt  source")  that  is  included  in  this  one.  In  other  words,  the  excerpt 
source  replaces  the  excerpt  element.  The  included  text  must  be  valid  in  the  context  in  which 
the  excerpt  element  occurs. 


-183- 


X3V1.8M/SD-7  Fifth  Draft 


The  attribute  quote  {quote)  indicates  whether  the  existence  of  the  inclusion  is  nnade  evident 
to  the  reader  of  this  document. 

The  attribute  excerpt  source  {xsource)  identifies  the  location  of  the  text  to  be  included.  It 
points  to  a  document  location  or  data  entity  location  element  that  describes  a  location  in  a 
document  other  than  the  one  in  which  this  excerpt  element  occurs. 

The  attribute  aciknowiedgmertt  {ack)  identifies  the  location  of  acknowledgment  data  for  the 
included  material,  such  as  a  copyright  notice.  The  acknowledgment  can  be  in  any  notation 
suitable  for  use  in  conjunction  with  the  included  material;  for  example,  an  image  that  can  be 
overlayed  on  an  included  video  clip. 


<! ELEMENT  excerpt 
<!ATTLIST  excerpt 


<!—  7.2.3    Excerpt  — > 

Part  of  another  document  included  in  this  one  — 
»  0         EMPTY  > 
id  ID  ^IMPLIED 

xsource    IDREF  ^REQUIRED 
quote      —  Reveal  existence  of  excerpt  — 

(quotejnoquote)  noquote  —  Default:  conceal  — 
ack         —  Acknowledgment  text 

IDREF      illMPLIED  > 


7.2.4    Location  Reference 

Applications  that  use  HyTime  will  frequently  define  specialized  link  elements  for 
cross-references  to  headings,  footnotes,  and  figures.  When  a  document  is  presented,  the 
reference  elements  are  replaced  by  the  heading  text,  footnote  numbers,  or  figure  captions  of 
the  elements  to  which  they  refer.  The  location  reference  element,  in  conjunction  with  the 
location  elements  defined  later,  offers  a  generalized  mechanism  for  such  cross-references. 

The  element  location  reference  {locref)  is  a  form  of  contextual  link  whose  other  link  end  is  a 
location  element.  An  application  will  normally  process  a  location  reference  by  replacing  it 
with  diata  that  is  derived  from  (but  is  not  necessarily  identical  to)  the  content  of  the  link  end. 

Note:  A  location  reference  therefore  differs  signficantly  from  an  entity  reference:  the 
latter,  is  an  SGML  construct  whose  behavior  is  defined  precisely  by  ISO  8879,  while 
the  behavior  of  a  location  reference  is  entirely  application-dependent. 


<!—  7.2,4   Location  Reference  — > 
<! ELEMENT  locref     —  Reference  to  a  location  element  — 

-  0         EMPTY  > 
<!ATTLIST  locref     id  ID  #IHPLIED 

idr         IDREF      #REQUIRED  » 


7.2.5  Locations 

A  general  link  must  refer  to  one  or  more  locations  in  documents.  SGML  provides  two 
inherent  constructs  for  identifying  locations: 

a)  A  unique  identifier  ("ID")  attribute,  which  identifies  a  complete  element  in  the  same 
document  as  the  reference  to  it. 


-184- 


X3V1.8M/SD.7  Fifth  Draft 


b)  An  entity  name,  which  identiries  a  complete  entity  (frequently  data  without  SGML  markup) 
in  the  same  document  from  which  it  is  referenced. 

These  constructs  are  insufficient  by  themselves  for  general  links,  because  the  link  ends  of  a 
general  link  could  be  outside  the  document  in  which  the  link  occurs,  or  they  could  constitute 
only  a  portion  of  a  data  entity  or  element.  For  these  reasons,  HyTime  supplements  these 
constructs  with  several  "location"  elements  that  can  be  used  separately  and  in  combination 
to  represent  the  following  locations: 

a)  In  a  data  entity,  a  point  or  a  span  of  data,  either. 

1)  in  terms  of  a  data  content  notation  (e.g.,  a  video  frame  number,  a  coordinate  in  space, 
an  offset  in  time);  or 

2)  in  terms  of  the  uninterpreted  characters. 

b)  In  an  SGML  document  or  subdocument  entity,  either 

1)  the  entire  document  or  subdocument;  or 

2)  some  identified  element  within  it;  or 

3)  some  data  location  within  the  identified  element  (interpreted  or  uninterpreted). 

Note:     ("EDITOR")  In  the  next  edition,  the  element  location  facility  will  be 
extended  to  address  a  span  from  one  element  location  to  another. 


7.2.5.1    Data  Entity  Location 

The  element  data  entity  location  (entloc)  identifies  a  portion  of  a  data  entity.  The  data  could 
be  "character  set  data."  or  it  could  be  "notation  data."  which  must  be  interpreted  according 
to  a  particular  data  content  notation.  The  portion  could  be  a  single  point,  or  a  span  of  data 
betv/een  two  points. 

The  attribute  data  entity  name  {dataent)  identifies  the  data  entity  to  which  the  data  entity 
location  refers.  If  not  specified,  the  data  entity  is  the  same  as  that  of  the  previous  entloc 
element. 


<!—  7.2.5,1   Data  Entity  Location  --> 
<! ELEMENT  entloc     —  Identifies  a  portion  of  a  data  entity  -- 

-  0  (cdloc  I  ndloc)  > 

<!ATTLIST  entloc     id  ID  ^REQUIRED 

dataent    ENTITY     #CURRENT  —  Default:  previous  entloc  — > 


Character  Set  Data  Location 

The  element  character  set  data  location  (cdloc)  defines  a  single  point  in  character  set  data, 
or  a  span  of  data  between  two  such  points. 

The  element  character  set  data  point  {cdpoint)  defines  a  point  in  character  set  data.  The 
point  is  represented  as  an  integer  offset  from  the  first  character  in  the  data.  A  value  of  0 
refers  to  the  point  prior  to  the  first  character,  except  when  only  one  cdpoint  is  specified  in  a 
cdloc,  in  which  case  it  refers  to  the  point  after  the  last  character 

Only  characters  that  an  SGML  parser  passes  to  an  application  are  counted  (for  example,  a 
record  end  after  a  start-tag  is  not  normally  treated  as  a  data  character). 


-185- 


X3V1.8M/SD-7  Fifth  Dralt 


<!—  7.2.4. LI   Character  Set  Data  Location  — > 
<!ELD1ENT  cdloc      —  Character  set  data  location  — 

—  0         (cdpoint,  cdpoint?)  > 
<! ELEMENT  cdpoint    —  Character  set  data  point  — 

—  Offset  from  first  significant  character  — 

—  9  »  before  first  char  (after  last  if  only  one  cdpoint)  — 
0  0         (#PCDATA)  > 


Notation  Data  Location 

The  element  notation  data  location  {ndloc)  defines  a  point  or  a  span  between  points  in  data 
that  is  subject  to  interpretation  by  a  data  content  notation.  The  representation  of  the  point  or 
span  is  not  defined  by  this  standard;  it  depends  upon  the  notation  in  which  the  data  itself  is 
represented. 

In  HyTime  applications,  the  data  would  normally  represent  occurrences  in  space,  time,  or 
both,  so  a  notation  data  location  would  consist  of  offsets  on  a  visual  coordinate  system, 
and/or  elapsed  time  values.  Some  notations  also  provide  the  ability  to  "label"  items  for 
identification,  in  such  cases,  a  notation  data  location  could  refer  to  such  labels. 

The  attribute  snap  {snap)  indicates  whether  the  specified  location  should  be  adjusted  to 
conform  to  alignment  or  synchronization  points  in  the  data.  The  specified  location  can  be 
"snapped"  to  the  nearest,  next  previous,  or  next  following  alignment  point,  or  not  at  all. 

Note:  Graphics  representations  commonly  have  an  associated  "grid"  to  which 
objects  can  be  "snapped"  in  order  to  assure  alignment  and/or  a  minimum  resolution. 
Similarly,  representations  with  an  internal  time  bases  frequently  include 
synchronization  points,  such  as  frame  markers  in  SMPTE  encoding  of  movies  and 
video. 

Note:  ("EDITOR'*)  It  may  be  possible  to  define  a  generalized  method  of  referencing 
space  and  time  locations  that  would  serve  for  a  wide  variety  of  notations.  Such  a 
method  could  be  incorporated  into  HyTime  as  the  definition  of  an  ndloc  element.  The 
snap  attribute  is  an  example  of  one  possible  parameter.  Suggestions  are  invited. 


<!—  7.2.4.1.2    Notation  Data  Location  — > 
<!ELEMENT  ndloc      —  Notation  data  location  — 

—  Offset  in  time  or  space  and  duration  or  size,  or  label 

-  0         (formula)  —  Depends  on  data  content  notation 
<!ATTLIST  ndloc      snap  Specified  point  is  changed  to  aligned  point  — 

(nearest! before i after  1  none)  none  > 


7^.5^    Document  Location 

The  element  document  location  (docloc)  identifies  a  portion  of  an  SGML  document  by 
means  of  an  optional  element  location,  and  an  optional  data  location  within  that  element.  If 
no  element  location  is  specified,  the  "element"  is  the  entire  document.  If  an  element 
location  is  specified,  but  no  data  location,  that  complete  element  is  the  "document  location." 

The  attribute  document  entity  {docent)  identifies  the  entity  in  which  the  document  begins.  If 
omitted,  it  is  the  same  entity  in  which  the  docloc  element  occurs. 


-186- 


X3V1.8M/SD-7  Fifth  Draft 


<!--  7.2.4.2    Document  Location  --> 
<!ELD-1ENT  doc^oc     —  Identifies  a  portion  of  a  document  or  subdocument  — 
--  Entire  document  if  element  location  is  omitted  —  . 

—  Entire  element  if  data  location  is  omitted  — 

-  0         (elemloc,  (cdloc  |  ndloc)?)?  > 
<!ATTLIST  docloc     id  ID  ^REQUIRED 

decent     ENTITY     #IMPLIED  ~  Default:  this  document  — > 


Element  Location 

The  element  element  location  {elemloc)  identifies  an  element  either  by  a  unique  name,  or  by 
a  sequence  of  "node  locations,"  called  a  "node  path."  The  element  location  permits  a 
general  link  to  refer  to  an  element  in  a  different  document,  or  to  an  element  (in  any 
document)  that  does  not  have  a  unique  identifier  attribute  ("ID"). 

The  attribute  element  identifier  {elemid)  is  the  unique  identifier  ("ID")  attribute  of  the 
element  whose  location  is  being  identified.  If  the  element  has  no  unique  identifier,  its  node 
path  is  used  instead. 

Notes: 


a)  The  attribute  elemid  is  not  declared  to  be  an  "IDREF"  attribute  because  its  value  may  be 
an  ID  from  another  document.  An  SGML  parser  will  normally  check  for  the  validity  and 
uniqueness  of  an  lOREF,  but  cannot  do  so  for  an  ID  from  another  document,  as  it  could 
conflict  with  an  ID  from  this  document. 

b)  The  keyword  "#CONREF"  identifies  a  "content  reference  attribute."  If  a  value  is  specified 
for  the  attribute,  the  SGML  parser  will  expect  the  content  to  be  empty  (and  vice  versa). 
The  application  is  expected  to  use  the  attribute  value  in  some  way  as  a  substitute  for  the 
data  that  would  ordinarily  have  been  in  the  content. 


<!—  7.2.5.2.1    Element  Location  --> 
<!ELEr'1ENT  elemloc    —  Identifies  an  element  of  a  document  or  subdocument  — 

-  0  (nodeloc+)  > 

<!ATTLIST  elemloc    elemid     NAME        #CONREF    -■■  Default:  use  node  path  — > 


Node  Location 

The  element  node  location  {nodeloc)  identifies  the  sequential  position  of  an  element  among 
its  siblings  in  the  tree  structure  of  the  document.  The  node  location  is  an  integer  greater 
than  zero,  and  each  separate  data  portion  in  mixed  content  is  treated  like  an  element  when 
counting. 

Note:  For  example,  in  a  paragraph  consisting  of  some  character  data  followed  by  a 
quotation  element,  and  then  some  more  character  data,  the  first  character  string 
would  have  a  node  location  of  "1,"  the  quotation  a  node  location  of  "2,"  and  the 
second  character  string  a  node  location  of  "3." 

Any  element,  including  the  pseudo-elements  containing  the  data  in  mixed  content,  can  be 
identified  uniquely  by  a  "node  path"  consisting  of  an  ordered  sequence  of  the  node  locations 
of  itself  and  its  ancestors,  starting  at  the  root  of  the  document  tree. 


-187- 


X3V1.8M/SD-7  Fifth  Draft 


Note:   For  example,  in  a  document  with  the  following  structure: 
<corexTrenseqxcesxce><ce></ces></mmseq><batonxtempo><tempo></baton></core> 
the  second  tempo  element  can  be  Identified  by  the  node  path: 
1  2  2 

An  element  that  is  empty  or  that  contains  only  data  (including  the  pseudo-elements 
containing  data  in  mixed  content)  is  a  leaf  of  the  document  tree.  Its  data  does  not  have  a 
node  location,  but  can  be  addressed  with  a  data  location  element. 


<!—  7.2.5.2.2    Node  Location  — ■> 
<! ELEMENT  nodeloc    —  Node  location:  integer  >  9  (each  fUPCDATA  is  one)  - 
-  0  (#PCDATA)  > 


7.2.5.3    Point  Location 

The  element  point  location  (pointloc)  Identifies  a  point  in  an  element  so  that  it  can  be 
referenced.  Its  content,  which  is  optional,  can  be  used  by  an  application  to  describe  the 
point. 

Mote:    For  example,  when  printing  a  cross-reference  to  it. 


<!—  7.2.5.3    Point  Location  --> 
<! ELEMENT  point! oc  —  Identifies  a  point  in  an  element  — 

Content  can  be  used  by  application  to  describe  point  — 

-  0  ANY  > 

<!ATTLIST  point! oc  1d  ID  #REQUIRED  > 


-188- 


Toward  Open  Hypertext:      Requirements  for 
Distributed    Hypermedia  Standards 

A  Position  Paper  for  the  NIST  Hypertext  Standards  Wori<shop 
Tim  Oren,  Apple  Computer 


1.  Directions    for    Hypertext  Standards 

Much  discussion  of  hypertext  standards  has  centered  on  the  transfer  of 
closed,  static  hypertext  document  bases  among  various  platforms  and 
organizations.     V/hile  there  is  an  undoubted  need  focused  on  the  use  of 
hypertext  with  optical  media  and  technical   documentation,  the  thesis  of 
this  position  paper  is  that  any  standard  based  primarily  on  this  limited 
application  will  be  necessarily  flawed. 

The  original  vision  of  hypertext  was  a  universally  shared,  dynamic 
"docuverse"  v/hich  could  be  read  and  written  by  all  users.  Although 
systems  short  of  this  grand  vision  have  proven  utility,  we  would  not  wish 
to  abandon  this  future  or  the  smaller  scale  visions  of  department  and 
enterprise-wide  hypertexts.        Nelson  proposed  that  one  unified  backend 
storage  mechanism,   "Xanadu,"  would   solve  the   distributed  hypertext 
problem  for  all  [Nelson  80].     Though  the  Xanadu  system  is  now  advancing 
toward  commercial  release,  it  comes  late  in  the  day.      There  are  already 
established  commercial  hypertext  systems  and  sizable  collections  of 
content  which  are  unlikely   to  be  abandoned. 

Hence,  if  we  want  the  docuverse  to  become  reality,  we  must  build  it  in  the 
distributed,  multivendor  computing  milieu  of  today.     To  bring  together 
the  diverse  software  and  hardware  systems  already  existing  we  will  need 
abstract  models  of  hypertext  and  ultimately  standards  based  on  the 
models.     If  this  work  is  to  be  viable,  the  results  must  also  reflect  technical 
and  market  realities,  and  interaction  with  other  areas  such  as  multimedia 
and  compound  documents  must  be  considered.     In  the  remainder  of  this 
paper,  I  examine  some  of  the  requirement  posed  by  these  constraints, 
propose  design  principles  for  meeting  these  requirements,   and  suggest 
that  an  open  system  architecture  should  be  the  ultimate  goal  of  hypertext 
standardization  efforts. 

2.  Technical  Conditions 

Working   in   today's   computing   environment   means   working   with  existing 
networking  and  file  standards.     These  are  characterized  by  loose 
connectivity  and  modest  reliability.     Not  only  do  LANs  and  WANs  break 
down,  but  many  connections  are  deliberately   noncontinuous  for  cost 
reasons.     Remote  resources  such  as  servers  fail  and  go  offline,  often  due 
to  crashes  that  mean  reloading  earlier  data  versions.       Existing  file  and 
device  level  utilities  allow  copying  and  alteration  of  file  and  document 
structures  without  warning  to  the  applications  which  rely  on  them.  All 
existing  standard  user  interface  systems  are  aimed  at  this  level.  These 
utilities  are  used  routinely  to  remove  partial  document  collections  for 


-189- 


work  at  home  or  transfer  to  other  sites,  and  to  return  modified  versions  to 
the  original  system.     A  hypertext  standard  for  this  environment  must  be 
robust  when  faced  with  a  variety  of  insults  to  document  identity  and  link 
integrity. 


layout  doc 


layout  doc 


\~I^JhTm  "comcosilo" would  be  more  fitting 
than  "compound",  but  "compounc 
document"  is  already  adopted  by  the 
international  standards  community. 

Page  7 


TV^jg  jg  a  Title 


table  doc 


mage  library  doc 


Figure  1.    Compound  document  Figure  2.    Hypermedia  document 

Activity   in  hypertext  standards  interacts   with  other  advanced  document 
models.     For  instance,  figure  1  shows  a  "compound  document"  where 
various  text  and  graphical  entities  (E)  are  assembled  into  a  page  under 
the  control  of  a  layout  specification.     However,  rather  than  storing  the 
compound  document  as  a  single  file,  it  might  be  realized  as  shown  in 
figure  2.     Here,  a  hypertext  substrate  is  used  to  implement  a  compound 
document:  the  graphic  entities  are  placed  using  links  (L)  to  persistent 
selections  (P)  within  other  files. 

Links  can  encode  dynamics  and  constraints  as  well  as  static  information. 
In  figure  2,  the  upper  link  specifies  the  transformation  of  the  linked  data 
into  a  graph.     In  figure  3,  links  are  used  to  specify  synchronization 
information  for  pieces  of  dynamic  media.     Finally,  as  suggested  in  figure 
4,  the  rise  of  object  oriented  software  may  make  possible  "component 
documents"  where  each  entity  may  be  edited  in  place  by  software  modules 
selected  at  runtime  by  the  user.     Implementing  a  component  software 
system  will  require  a  standard  data  storage  substrate  very  similar  to 
hypertext  which  vendors  of  individual  components  can  use  and  extend. 

Because  these  issues  and  applications  all  interlock,  it  is  not  possible  to 
restrict  a  discussion  of  hypertext  standards  to  static  text  alone  or  to 
particular  document  models.     A  standard  arrived  at  in  this  fashion  will 
suffer  one  of  two  fates.    At  best,  it  will  create  a  "golden  ghetto"  where  a 
class  of  hypertext  applications  may  live,  but  without  connecting  to  other 
media  types  or  document  models.    At  worst,  it  may  coopt  and  prevent 
progress   in  these  areas. 


-190- 


storyboard  document 


video  document 


0:00:00 


0:07:19 


0:08:35  , 


The^ 


Opening  scene. 
Fade  in  on  LS  of  the 
street. 

Cut  to  MS  of 
leopard. 

Sound  efx  "ROAR". 
Overlay  "The  end".^ 


animation  document 


audio 
document 


Figure  3.     Multimedia  documents 


Secretariat 


# 

Secr-t 

avg 

1 

177.66 

680.00' 

2 

996.10 

10.00 

3 

314.14 

199.91 

This  I  e ) 
shows  somt 
runaround  tc 
show  that  Iho 
layout  isn't  jusi 
rectangles. 

The  relations  between  frames  is  more 
complex  than  window  panes.  When 
a  picture  frame  gets 
wider,  the  adjacent 
text  column  get: 
narrower  and  thus 
longer,  which  may 

wrap  to  another  column.  This  may  move 
another  frame  to  a  new  page.  Frames  may 
even  overlap! 

This  document  requires  "fine-grainec 
window  management'  for  its  window. 


a  gallop 


Plug-in  software 
components 

Entities  are  edited  in  place 

The  composition  and  text 
blocks  could  also  be  plug-in 
components 


Figure  4.     Component  documents 

In  these  examples  the  objects  are  not  exclusively  text.     They  include  static 
bit  map  graphics  and  object  graphics,  dynamic  animation,  sound  and 
video.     Each  of  these  data  types  represents  a  corresponding  discipline  and 
standards  effort.     A  hypertext  standard  which  restricts  itself  to  text  alone 
is  crippled  at  the  beginning.     One  which  attempts  to  reinvent  standards 
for  each  constituent  media  type  would  create  a  ghetto  effect,  and  might  be 
simply  impractical  given  the  effort  required.     It  would  seem  that  a 
hypertext  standard  must  find  a  way  to  embrace  existing  media  type 
standards  with  a  minimum  of  modification.     In  the  remainder  of  this 


-191- 


discussion,  I  use  hypertext  in  its  most  general  sense,  to  indicate  the 
scheme  for  linking  all  data  types,  not  just  text. 

Hypertext  as  a  functioning  discipline  is  quite  young,  and  disagreement 
and  lack  of  understanding  of  systems  architecture  and  application  needs 
is  still  rife.     There  is  controversy  at  even  the  fundamental  level  of 
linking  method   and  storage  organization.      Various  systems  implement 
links  as  separate  webs  or  within  documents,  and  represent  them 
abstractly  or  procedurally.     A  recent  panel  on  system  architecture  makes 
it  clear  that  there  is  still  substantial  change,  with  many  systems  seeking 
to  adapt  the  better  features  of  the  other  approaches  [Halasz  89].    It  is  also 
clear  that  the  diversity  of  systems  is  not  gratuitous  variation,  but  has 
occurred  because  of  real  differences  in  the  intended  applications  and 
audiences.     No  "one  right  way"  to  do  hypertext  has  emerged. 

Above  the  storage  level,  diversity  increases  further.     Labelled  links  are 
used   diversely,   to   represent   constraints,   timing,   inferencing  and 
rhetorical  information  for  the  use  of  both  the  browser  and  the  software. 
User  interfaces  to  large,  interlinked  data  stores  are  an  area  of  active  and 
fruitful   research.      More  complex   architectural   issues  such   as  versioning 
and  searchability  are  just  beginning  to  be  explored.     Again,  the  various 
approaches  and  progress  have  been  largely  driven  by  the  needs  of 
particular  applications. 

Attempts  to  standardize  in  a  discipline  in  such  flux  must  take  account  of 
the  diversity  of  approaches  if  they  are  not  to  cripple  progress.     To  the 
greatest  extent  possible,  formalisms  must  embrace  the  diversity  of 
architectures   and   applications   rather  than   being   exclusive  or 
prescriptive. 

3.    Market  Conditions 

A  standard  must  consider  prevailing  market  conditions  to  be  effective.  In 
the  case  of  distributed  hypertext,  the  installed  base  of  machines  on 
networks  is  characterized  by  wide  diversity  of  vendor,  architecture,  and 
hypertext  software.      Significant  hypertext   systems  run  on  Macintoshes, 
IBM  PCs  and  PS/2s,  Sun,  DEC  and  other  Unix  equipment,  interconnected 
with  a  variety  of  LAN  architectures,  many  also  connected  to  long  haul 
networks  such  as  Bitnet  or  Milnet.     Hypertext  software  is  provided  by  both 
hardware   vendors   (HyperCard,    Sunlink)   and    independent  software 
vendors  (KMS,  HyperTIES,  Guide).     Initial  market  penetration  of  hypertext 
technology  is  occurring  in  the  areas  of  in-house  and  external  technical 
documentation   and   distribution   of  multimedia  content,   particularly  on 
optical  discs.     Substantial  commercial  and  academic  efforts  are  underway 
to  introduce  hypertext  as  a  mechanism  for  collaborative  work  in  the 
computing  environment. 

Given  this  diversity  of  platforms,  the  resemblance  of  distributed 
hypertext  to  the  open  systems  efforts  undertaken  in  networking  and 
structured  databases  is  obvious.     The  existing  vendors,  applications,  and 
users  will  not  be  dislodged  by  either  a  proprietary  specification  such  as 
Xanadu  or  a  public  standard.     A  successful  effort  must  coopt  existing  users 
by  extending  their  reach  onto  other  platforms.     It  should  become  possible 


-192- 


to,  for  example,  read  nodes  within  HyperCard  without  being  necessarily 
aware  that  they  reside  in  a  remote  database  created  in  HypcrTIES. 

The  technical  issue  of  non-textual  data  also  has  a  market  component.  Not 
only  do  standards  for  various  data  types  evolve  separately,  but  the 
markets   for  the   underlying  technology   in   hardware   and  software 
progress  at  their  own  speed.     Of  particular  importance,  there  is  often  a 
succession  of  dominant  applications  within  a  media  type.     For  instance,  on 
the  Macintosh,  MacPaint  was  surpassed  in  turn  by  SuperPaint  and 
PixelPaint.     A  standard  must  accommodate  this  process  in  two  ways.  First, 
it  must  not  bind  data  tightly  to  its  creating  application,  in  order  that  the 
user  may  replace  it  with  another  at  a  later  date.     Second,  the  standard 
must  be  extensible,  to  allow  vendors  to  compete  on  features  without  being 
required  to   abandon  the  standard. 

Another  market  phenomenon  is  the  decline  of  the  so-called  "integrated 
application."     The  required  feature  set  within  each  data  type  has  become 
so  large  that  a  project  or  product  which  attempts  to  do  all  becomes 
impractical.      Integrated  applications  linger  only   at  the  novice  level. 
Much  integration  is  now  done  by  cut-and-paste  or  data  piping  facilities  at 
the  operating  system  level. 

Hypertext  may  be  viewed  as  the  next  logical  evolution  of  integrated 
applications,  with  the  ability  to  freely  browse  between  all  data  types. 
Given  the  issues  outlined  above,  it  follows  that  the  hypertext  facility  will 
need  to  be  implemented  at  the  system  level  to  be  effective.     A  successful 
standards  effort  must  then  include  platform  vendors  and  provide  a 
mechanism   for  their  joint  efforts. 

The  hypertext  market  is  quite  young.     Many  of  the  software  vendors  are 
startup  ventures  and  are  thin  on  capital  and  engineering  resources.  A 
successful  standard  must  address  this  problem  by  making 
implementations  available  to  such  developers  at  very  low  cost.     Failure  to 
do  this  would  confine  use  of  the  standard  to  high-end  markets  where 
firms  and  clients  can  afford  the  engineering  overhead  to  implement  the 
standard.     It  would  also  cut  the  standard  off  from  the  most  innovative 
sector  of  the  software  market.     Even  a  low  cost  standard  must  present 
convincing  advantages  in  integration,  power,   and  room  for  growth  if 
developers  are  to  give  up  proprietary  schemes  of  data  storage. 

4.    Design    Principles    for    a    Hypertext  Standard 

What  principles  can  be  deduced  from  these  technical  and  market 
constraints?     First,  a  standards  effort  must  start  with  the  creation  of  an 
abstract  model  of  hypertext  which  is  as  inclusive  as  possible.  Because 
many   existing   hypertext   systems   were   tightly   driven   by  application 
scenarios,  this  means  looking  at  a  variety  of  user  communities  needs. 
Particularly,  building  any  system  architecture  driven  by  the  needs  of  one 
application  area  into  a  standard  would  be  inadvisable.     The  work  of  the 
Dexter  Hypertext  Model  is  a  useful  precedent  in  this  area  [Halasz  90]. 

Any  standard  must  be  portable  to  the  greatest  extent,  not  dependent  on 
particular   processor,    display,    network,    or   peripheral  architectures. 
Portability  will   allow  the  greatest  degree  of  interoperability  in  the 


-193- 


current  computing  environment,  and  guarantee  survivability  onto 
succeeding    generations    of  technology. 


Given  the  need  to  incorporate  existing  data  type  standards  and  allow  the 
implementing   software   to   evolve    independently,    a   hypertext  standard 
must  support  modularity.     Data  items  may  be  incorporated  by  reference  to 
an  existing  file  as  well  as  by  inclusion  within  a  standard  form  hypertext. 
Extensions  to  existing  standards  to  incorporate  hypertext  features  should 
be  minimal. 


A  hypertext  standard  must  be  extensible  to  support  the  rapid  evolution  of 
both  data  type  specific  software  and  notions  of  usage  of  links.     Any  typing 
mechanism  built  into  the  hypertext  definition  must  be  open  to  extension. 
Methods  must  be  provided  for  superseding  one  representation  of  a  data 
element   with   another  without   disrupting  the  entire   hypertext.  Facilities 
must   be   provided   for   incorporating   proprietary   data   representations  with 
the  facility  to  point  at  parallel  standard  representations. 


T 


179.82 


179.82 


179.82 


179.82 


179.82 


rflta,i»,g,feg«ign. 
tot  jtitg,fttft.nig.atit..:tff..iw.»fft)>  a. 


A 

_B 

1 

179.82 

179.82 

2 

179.82 

179.82 

ii 

179,82 

179.82 

^entities  can  move 
between  documents  and 
stili  be  editable 

♦  documents  can  move 
between  machines  and 
link  adaptively 


itssdsseaBL, 
to  han.^.  )> 


1  A 

B 

179.82 

179.82 

2 

179.82 

179.82 

179.82 

179.82 

/  (missing  / 
^  picture)  ^ 


Figure  5.     Separability:     Moving  data  around 


A  principle  termed  "separability"  is  important  to  coexistence  with  today's 
file  and  network  systems.     This  entails,  first,  a  level  of  data  organization 
called  "entities."     An  entity  encapsulates  sufficient  data  and  metadata  that 
it  may  be  moved  or  copied  between  files  without  loss  of  information.  For 
instance,  an  animation  data  entity  might  contain  a  series  of  frames, 
persistent  selections  for  linking,  a  color  lookup  table  (GLUT),  and  a 
description  of  the  required  screen   resolution   and  depth   and  processor 
resources.     This  could  be  moved  in  its  entirety,  while  copying  the  frames 
alone  would  lose  information  as  they  were  moved  out  of  context.     Figure  5 
illustrates  this  concept,  as  well  as  the  related  feature  that  entities  must  be 
robust  in  the  face  of  missing  linked  data.     In  the  partial  hypertext 
extracted  to  a  remote  machine  the  library  image  is  missing,  but  sufficient 


-194- 


layout  information  remains  to  block  out  its  location  and  allow  work  to 
proceed. 

Separability  must  be  supported  with  identity  and  inspectabilily.     A  robust 
identity  mechanism  allows  an  implementing  system  to  detect  if  a 
referenced  entity  is  missing  or  present  in  duplicate.     Note  that  identity 
may  be  separated  from  the  particular  mechanism  which  a  system  uses  to 
find  the  referenced  entity.      Various   implementations  might   keep  merged 
databases  of  entity  identity  vs.  location,  or  resolve  references  using 
heuristic   mechanisms  peculiar  to   a  platform. 

Inspectabilily  means  that  the  interdependencies  of  entities  must  be 
apparent  to  a  utility  which  understands  the  linkage  standards  only,  and 
has  no  knowledge  of  the  internal  structure  of  data  entities.     Such  a  naive 
utility  may  then  copy  or  move  portions  of  the  hypertext  without  a  need 
for  extensions  as  new  entity  types  are  added. 

To  allow  room  for  the  evolution  of  hypertext  technology,  a  layered 
standard  will  be  necessary.       To  permit  layering,  each  portion  of  the 
standard  must  be  policy  neutral.    This  means  that  it  must  allow  a  wide 
range  of  choices  in  how  it  is  applied  by  higher  layers.     For  instance,  a 
standard  which  specified  link  formats  and  also  required  their  storage  in  a 
single  "web"  would  not  be  neutral,  because  it  enforces  a  particular 
implementation.      A  policy  neutral   formulation  would  specify  the  format 
and  possibly  behavior  of  links  without  specifying  in  what  place(s)  they 
must  be  stored.     Policy  neutrality  also  permits  the  delegation  of  certain 
design  choices  to  implementors,  and  provides  degrees  of  freedom  for 
technical  issues  with  no  current  solution.     These  issues  include  the 
division  of  entities  and  linkage  information  between  files,  link  typing 
and  usage,  searchability  and  version  management.     Again,  an  abstract 
model  is  helpful  in  creating  the  generalizations  needed  for  policy 
neutrality. 

Standards  may  be  expressed  as  data  formats  or  as  behaviors.     A  hypertext 
standard  expressed  as  an  explicit  data  format  is  probably  necessary  to 
support  environments  where  only  serial  ASCII  or  binary  data  is  available. 
This  is  typical  of  the  bulk  transfer  of  reference  hypertexts  between 
machines.     However,  such  a  format  is  poorly  adapted  for  update  and 
search.     Neutrality  of  applications  is  better  provided  by  standardization  at 
the  behavioral  level  of  an  application  program  interface  (API).  A 
compliant  implementation  might  simply  provide  access  to  the  standard 
serial  hypertext  form,  but  would  more  likely  implement  a  random  access 
or  object-oriented  filing  mechanism   adapted  for  its  particular  platform. 
The  distributed  open  hypertext  environment  is  then  implemented  as 
peer-to-peer   conversations   among   compliant   implementations   of  the 
standard. 

5.  Conclusions 

Standards  must  be  approached  cautiously  in  a  field  as  new  as  hypertext. 
While  we  may   need   interim   or  experimental   specifications   for  particular 
application  areas,  making  the  exchange  of  static  hypertexts  the  subject  of 
a  standard  is  undesirable.     Decisions  which  we  make  will  necessarily 
affect  other  areas  such  as  multimedia  and  compound  documents.  A 


-195- 


premature  standard  could  have  the  effect  of  ghettoizing  a  subset  of 
hypertext.     The  goals  of  a  hypertext  standard  should  be  the 
implementation  of  the  vision  of  distributed  hypertext  within  an  open 
systems  framework. 

6.  Acknowledgements 

This  paper  is  based  on  extensive  discussions  with  Jerry  Morrison  and 
Richard  Moore,  my  colleagues  at  Apple  Computer,  and  was  also  influenced 
by  members  of  the  Dexter  Hypertext  Workshops,  particularly  Norm 
Meyrowitz,  Randy  Trigg,  Amy  Pearl,  Frank  Halasz  and  Mayer  Schwartz. 

7.  Bibliography 

[Halasz  89]  Halasz,  Frank,  et.  al.,  "Panel:  Confessions  —  What's  Wrong  with 
our  Systems,"  given  at  Hypertext  '89,  November  5-8,  1989,  Pittsburgh,  PA. 

[Halasz  90]  Halasz,  Frank  and  Mayer  Schwartz,  "The  Dexter  Hypertext 
Model,"  to  be  presented  at  NIST  Hypertext  Standards  Workshop,  January 
16-18,  1990,  Gaithersburg,  MD. 

[Nelson  80]  Nelson,  T.,  "Replacing  the  printed  word:  A  complete  literary 
system,"  Proceedings  of  IFIP  Congress  1980.  North-Holland,  1013-1023, 
1980. 


-196- 


Toward  a  Reference  Model  for  Hypermedia 
H.  Van  Dyke  Parunak 
Industrial  Technology  Institute 
P.O.  Box  1485 
Ann  Arbor,  MI  48106 
(313)  769-4049,  van@iti.org 
7  December  1989 

Abstract 

A  necessary  first  step  in  discussing  standardization  in  a  domain  is  the  development  of 
a  reference  model  for  that  domain,  a  high-level  framework  within  which  specific  topics 
for  discussion  can  be  defined  and  discussed.  This  paper  offers  a  "straw"  version  of  such 
a  framework  as  a  basis  for  discussion,  and  discusses  the  "standardizability"  of  various 
detailed  subjects  within  that  framework. 

1.  Introduction 

A  reference  model  is  a  high-level  description  of  a  domain  within  which  discussion  of 
more  detailed  subjects  can  be  situated.  As  a  mechanism  for  setting  the  context  of  a 
domain,  reference  models  have  been  useful  in  several  fields.  This  section  gives  examples 
of  other  reference  models,  suggests  some  of  the  uses  to  which  they  may  be  put,  discusses 
why  a  reference  model  is  desirable  for  hypermedia,  and  outlines  the  high-level  structure 
of  a  proposed  reference  model  for  hypermedia. 

1.1.  Examples  of  Other  Reference  Models 

Reference  models  have  been  proposed  in  many  domains,  including  telecommunications, 
factory  control  architectures,  and  material  handling  architectures. 

Perhaps  the  best  known  reference  model  is  the  ISO-OSI  seven-layer  model  for 
telecommunications. [DAY83]  By  articulating  the  various  communications  functions  and 
defining  an  ordered  relation  among  them,  this  model  has  supported  a  vigorous  and 
productive  standardization  effort. 

A  number  of  studies  have  proposed  reference  models  for  manufacturing  control; 
[PARU87]   provides   a  useful  summary,   and   [BIEM89,  \VILL89]   are   more  recent 


-197- 


treatments.  These  studies  have  been  motivated  by  the  growing  interest  in  integrated 
manufacturing,  and  the  resulting  need  to  relate  the  various  entities  in  a  manufacturing 
enterprise  to  one  another  in  a  consistent  way. 

In  the  domain  of  material  handling,  the  OSI  model  has  been  adopted  to  define  a 
layered  model  for  the  transport  of  material, [PARU88|  and  this  model  has  been  used  as 
the  basis  for  experimental  implementations  in  our  laboratory. 

1.2.  The  Uses  of  a  Reference  Model 
A  reference  model  is  useful  for  description,  standardization,  design,  and  innovation. 

It  provides  a  descriptive  framework  for  comparing  existing  systems  in  its  domain,  and 
in  fact  is  often  compiled  by  surveying  existing  systems  for  similarities  and  differences. 
_  It  thus  provides  an  underlying  ontology  of  its  domain. 

By  identifying  the  critical  subjects  in  the  domain  and  showing  how  they  are  related  to 
one  another,  it  provides  a  context  for  standardization.  It  facilitates  discussion  of  what  is 
and  is  not  ready  for  standardization,  identifies  specific  subjects  for  standards,  and  calls 
out  where  subsystems  (and  thus  the  standards  that  describe  them)  must  interface  with 
one  another. 

As  a  high-level  analysis  of  its  domain,  a  reference  model  guides  the  designer  of  a  new 
system  in  identifying  the  Issues  that  must  be  addressed  and  the  broad  functions  that  the 
system  must  provide,  as  well  as  suggesting  the  kinds  of  solutions  that  have  been 
attempted  in  the  past. 

Reference  models  not  only  help  to  mature  a  field  through  development  of  standards 
and  common  analyses,  but  can  also  foster  innovation.  At  the  detailed  level,  by 
partitioning  the  problem,  they  invite  the  development  of  new  solutions,  showing  what 
has  already  been  tried.  At  a  higher  level,  they  invite  creative  thinkers  to  challenge  their 
overall  structure  and  thus  introduce  new  paradigms. 


-198- 


The  descriptive  and  prescriptive  functions  of  a  reference  model  are  in  natural  and 
unavoidable  tension.  As  a  guide  to  classifying  existing  systems  and  as  a  pointer  to 
needed  innovation,  a  reference  model  should  be  as  comprehensive  as  possible,  able  to 
embrace  any  implementation  of  the  domain.  As  a  roadmap  for  standardization  or  a 
guide  for  designers,  it  should  embody  design  choices  that  reflect  good  practice  and 
sound  engineering,  and  thus  be  selective.  It  seems  reasonable  to  expect  that  reference 
models  will  follow  a  life-cycle  that  moves  from  broad  and  descriptive  to  selective  and 
prescriptive.  While  it  may  be  premature  to  build  prescriptive  models  of  hypermedia,  it 
is  not  at  all  too  early  to  formulate  broad  descriptions  of  the  underlying  technologies, 
descriptions  that  through  time  can  evolve  into  more  selective  models. 

1.3.  Why  a  Reference  Model  for  Hypermedia? 

A  reference  model  for  hypermedia  is  desirable  not  only  for  helping  the  technology  to 
mature,  but  also  for  fostering  its  development  as  a  distributed  tool. 

Every  worker  in  a  domain  has  an  individual  "reference  model"  of  that  domain  within 
which  various  contributions  to  the  field  are  implicitly  classified  and  assessed.  A  textbook 
in  a  domain  is  essentially  an  instantiation  of  such  a  model,  and  helps  newcomers  to  the 
domain  to  put  in  place  a  mental  framework  within  which  to  operate.  The  rapid  growth 
of  interest  in  hypermedia  makes  this  educational  service  particularly  desirable  in  the 
case  of  hypermedia.  However,  if  this  were  the  only  motive,  it  is  questionable  whether  a 
joint  activity  to  develop  such  a  model  would  be  justified. 

The  need  for  a  jointly  developed  model  arises  from  the  potential  of  hypermedia  as  a 
distributed  technology.  Hypermedia  is  distributed  in  at  least  two  ways.  First,  it  has 
proven  to  be  a  useful  medium  for  managing  the  collaboration  of  teams  of 
workers. [CONK87,  HALA87]  Thus  it  is  often  implemented  as  a  distributed  application, 
with  the  resulting  need  for  standards  to  insure  that  the  various  components  of  such  an 
application  are  consistent  with  one  another  and  can  be  maintained  in  a  modular 
fashion.  This  motive  for  standardization  becomes  especially  strong  when  the  components 
are  not  operating  in  a  homogeneous  environment.  Second,  the  information  that  is  linked 


-199- 


together  in  a  hypermedia  system  is  often  distributed  in  the  sense  of  being  of  differing 
types  and  origins.  The  ability  of  a  hypermedia  system  to  access  generic  materials 
without  expensive  recoding  and  preprocessing  will  depend  on  the  rapid  development  and 
broad  dissemination  of  standards  for  the  production  and  encoding  of  machine-readable 
information. 

1.4.  A  Possible  High-Level  Structure 

The  reference  model  sketched  in  this  paper  is  described  from  three  perspectives:  the 
functional  elements  of  a  hypermedia  system,  implementation  concerns,  and  interface 
issues.  We  will  outline  the  main  elements  to  be  considered  in  each  of  these  areas,  and 
also  suggest  the  applicability  of  standards  to  each  area. 

2.  Elements  of  Hypermedia 

The  two  basic  elem.ents  of  a  hypermedia  system  are  nodes  of  information  and  links 
that  join  them  together.  In  addition,  recent  research  suggests  that  the  usability  of 
hypermedia  depends  on  the  disciplined  use  of  structured  composites  of  nodes  and  links 
as  higher-order  entities. 

2.1.  Nodes 

The  nodes  of  a  hyperbase  are  the  units  of  information  that  it  assembles  together  and 
among  which  it  provides  ready  movement.  The  nodes  in  a  system  can  be  described 
from  the  perspective  of  their  contents,  their  typing,  and  their  structure. 

2.1.1.  Node  Contents 

The  very  name  "hypertext"  suggests  that  virtually  every  hypermedia  system  can 
present  information  in  the  form  of  text.  Most  implementations  support  some  form  of 
graphic  display  as  well.  Animation,  video,  and  audio  are  less  common  but  have  been 
demonstrated.  [BIEB89]  suggests  generalizing  the  notion  of  a  node  to  "any  information 
item  about  which  the  system  can  reason."  Such  a  definition  permits  a  node  to  be 
executable  code  that  is  invoked  when  the  link  leading  to  it  is  traversed,  thus  leading  to 
any  conceivable  kind  of  computer  operation.  In  fact,  some  early  antecedents  of 
hypertext  were  menu  systems,  in  which  all  leaf  nodes  were  of  this  sort. 


-200- 


As  long  as  nodes  are  treated  as  atoms,  there  is  no  difficulty  with  such  a  variety  of 
node  contents.  For  many  purposes,  one  must  define  locations  within  nodes,  either  as 
destinations  or  as  origins  for  a  link.  The  mechanisms  for  such  definition  are  highly 
dependent  on  node  contents.  For  example: 

•  Because  text  is  one-dimensional,  location  in  a  textual  node  is  conveniently 
defined  on  the  basis  of  characters. 

•  In  graphical  nodes,  location  is  defined  two-dimensionally  on  the  basis  of 
pixels. 

•  Animation  and  video  invite  the  same  pixel-based  definition  of  location  as 
does  graphics,  but  there  is  an  additional  time  dimension. 

•  Location  in  an  audio  node  is  most  readily  defined  temporally. 

•  In  a  node  consisting  of  executable  code,  the  instruction  counter  is  a 
reasonable  measure  of  location.  If  the  node  processes  user  input,  location  can 
be  defined  in  terms  of  the  possible  user  trajectories  through  the  program. 

2.1.2.  Node  Typing 

In  addition  to  different  contents,  nodes  may  also  have  different  types.  Node  typing  is 
most  often  important  in  the  context  of  typed  links.  For  instance,  in  gIBIS,  a  Supports 
link  can  only  appear  between  a  node  of  type  Argument  and  one  of  type 
Position.[CONK87]  Together  with  link  typing,  node  typing  permits  the  definition  of  a 
grammar  or  rhetoric  over  a  hyperbase,  and  greatly  facilitates  user  navigation  and 
automatic  information  retrieval. 

2.1.3.  Node  Structure 

The  measures  of  location  defined  above  for  nodes  of  differing  contents  are  sometimes 
too  primitive  for  convenient  use.  For  example,  one  can  define  words  or  sentences  in  a 
textual  node,  buttons  or  sliders  in  a  graphical  node,  musical  phrases  in  an  audio  node, 
or  positions  in  a  user  trajectory  in  an  executable  node,  hiding  the  corresponding 
characters,  pixels,  time  intervals,  or  instruction  counts  as  implementation  details.  Then 
links  can  originate  or  terminate  at  these  higher-order  objects.  Consistent  definition  of 
such  higher-order  objects  and  their  mappings  to  lower-order  entities  offer  a  good 
opportunity  for  standardization. 


-201- 


2.2.  Links 

A  discussion  of  links  in  a  hypermedia  system  requires  definition  of  directionality, 
topology,  types,  anchors,  and  modes. 

2.2.1.  Link  Directionality 

A  link  is  directional  if  its  ends  are  differentiated  in  some  way  from  one  another. 
Often,  the  mechanism  for  traversing  a  directional  link  in  one  direction  is  different  from 
that  used  in  the  other  direction.  For  instance,  links  in  Intermedia  are  not  directional. 
The  same  icon  marks  both  ends  of  the  link,  and  the  same  operation  traverses  it  in  both 
directions.  In  HyperTies,  links  are  directional,  and  the  backward  direction  is  usually 
only  accessible  if  one  has  already  traversed  the  link  in  the  forward  direction. 
Cognitively,  directional  links  can  be  a  valuable  aid  to  navigation  in  a 
hyperbase.[PARU89] 

2.2.2.  Link  Topology 

Current  systems  typically  do  not  constrain  the  overall  topology  that  links  can  form, 
but  user  navigation  depends  critically  on  this  topology,  and  there  are  strong  cognitive 
motives  for  disallowing  arbitrary  topologies.  [PARU89]  The  number  of  possible 
topologies  is  countably  infinite,  but  important  major  classes  are  linear,  hierarchical, 
hypercube,  and  DAG. 

2.2.3.  Link  Types 

By  defining  various  types  of  links  (and  typically  correlating  them  with  typed  nodes), 
we  can  enrich  the  rhetorical  capabilities  of  a  hyperbase,  as  discussed  above  under  "Node 
Types." 

2.2.4.  Link  Anchors 

The  anchors,  or  endpoints,  of  a  link  are  its  origin  and  its  destination.  The  destination 
of  a  link  can  either  be  a  node  as  an  atomic  unit,  or  some  entity  contained  within  the 
node.  In  the  case  of  a  structured  node,  this  entity  will  be  some  element  of  the 
structure.  In  the  case  of  an  unstructured  node,  this  entity  will  be  either  a  point  or  a 
region  defined  by  whatever  measure  of  location  is  appropriate  to  the  node's  contents. 


-202- 


If  links  are  constrained  to  originate  wit?i  nodes  as  atomic  units,  the  resulting 
hyperbase  will  have  a  linear  topology,  which  forfeits  the  more  interesting  features  of 
hypermedia.  Thus  at  least  the  origins  of  links  are  some  element  within  a  structured 
node  or  some  location  or  region  within  an  unstructured  node. 

2.2.5.  Link  Modes 

The  simplest  form  of  a  link  is  a  fixed  connection  between  two  anchors  (either  nodes  or 
entities  within  nodes).  The  order  of  processing  a  link  is  usually  select-traverse-display. 
Both  the  form  and  the  processing  of  a  link  can  be  expanded  [BIEB89];  a  link  can  be 
virtual  (computed  at  run-time)  rather  than  fixed,  and  inferencing  can  be  added  both 
before  and  after  link  traversal.  Such  additional  inferencing  can  be  used  to  implement 
such  modes  of  linking  as  warm  links  (in  which  users  can  push  or  pull  data  over  a  link) 
and  hot  links  (in  which  data  modified  at  one  end  of  the  link  is  automatically  updated 
on  the  other  end).[CATL89j 

2.3.  Composites 

There  has  been  a  growing  realization  among  workers  in  hypermedia  that  usable 
hyperbases  require  the  ability  to  manipulate  composite  entities:  entities  that  are  larger 
than,  and  made  up  of,  individual  nodes  and  links. [HALA87]  Such  composites  can  be 
defined  either  rhetorically  or  topologically. 

Paths  [ZELL89]  are  a  simple  example  of  a  topological  composite.  A  bare  network  of 
links  and  nodes  is  well-suited  to  random  browsing,  but  many  applications  of 
hypermedia  presuppose  a  basic  trajectory  through  the  hyperbase,  with  the  rest  of  the 
material  available  as  needed.  Paths  support  such  applications  by  giving  writers  a  way  to 
define  a  backbone  that  readers  should  follow,  and  to  which  they  can  readily  return  after 
any  digressions.  Topologically,  the  path  imposes  a  linear  topology  on  a  much  more 
complicated  network,  thus  combining  the  cognitive  advantages  of  the  simpler  topology 
with  the  fiexibility  of  the  more  complex  one. 

Rhetorical  composites  are  specific  constellations  of  (usually  typed)  nodes  and  links 
that  form  a  logical  unit  for  manipulation  and  navigation.  For  example,  the  Toulmin 


-203- 


argumentation  schema  [TOUL69,  STRE89]  represents  an  argument  as  a  composite  of 
nodes  that  articulate  a  claim,  its  supporting  datum,  the  warrant  and  backing  that  make 
the  datum  relevant  to  the  claim,  and  any  rebuttal.  Derivatives  of  IBIS  such  as  gIBIS 
focus  on  the  basic  tree  consisting  of  an  issue,  various  positions  on  that  issue,  and  the 
arguments  for  and  against  each  of  the  positions. [CONK87| 

2.4.  Element  Standardization 

The  elements  that  we  have  discussed  form  the  ontological  foundation  of  hypermedia, 
suggesting  that  at  least  common  terminology  needs  to  be  defined  if  standardization  of 
any  aspect  of  hypermedia  is  to  be  possible.  This  basic  ontology  is  stable  enough  that  the 
outlines  of  a  reference  model  constructed  now  will  probably  be  able  to  accommodate 
new  techniques  as  they  are  developed,  by  adding  subpoints  as  appropriate. 

3.  Implementation  Concerns 

Here  we  address  both  architectural  and  programming  issues. 

3.1.  Layered  Architecture 

Architecturally,  there  is  a  growing  consensus  in  favor  of  the  value  of  a  layered 
architecture  for  hypermedia.  This  approach  has  been  applied  both  to  data 
communications  [DAY83]  and  the  control  of  material  handling  [PARU88].  It  not  only 
permits  modular,  maintainable  programs,  but  also  facilitates  access  of  a  layered  system 
by  other  systems  that  know  the  services  published  at  each  layer.  Thus  a  layered 
architecture  facilitates  the  development  of  hyperbases  that  can  interact  with  one 
another  as  well  as  with  users. 

At  least  four  layers  are  useful  for  a  layered  hypermedia  architecture:  data,  element, 
inference,  and  interface. 

3.1.1.  Data 

The  data  layer  provides  consistent  data  management  for  all  information  in  the 
hyperbase,  including  both  the  contents  of  nodes  and  the  links  among  nodes.  If 
development  and  browsing  of  a  hyperbase  are  to  be  separate  processes,  this  layer 


-204- 


manages  access  permissions  to  implement  read-only  networks.  In  a  multiuser 
hyperbase,  this  layer  must  support  multiple  access  with  appropriate  consistency 
management.  Many  applications  will  require  it  to  support  versioning  as  well.  As 
hypermedia  becomes  more  widely  applied,  distributed  hyperbases  will  develop  that  will 
require  the  data  layer  to  provide  distributed  data  access,  and  in  this  case  it  would 
logically  be  defined  as  an  RDA  application  on  top  of  an  OSI  stack. 

3.1.2.  Element 

The  element  layer  provides  separate  services  for  managing  nodes  and  links,  and 
translates  the  raw  data  of  the  data  layer  into  these  atomic  elements  of  hypermedia.  The 
value  of  storing  links  separately  from  nodes  is  becoming  evident,  and  is  supported  in 
Intermedia  and  in  the  link  service  furnished  with  Sun's  Network  Softv/are 
Environment.  [PEAR89]  Among  other  benefits,  this  separation  permits  users  to  have 
private  sets  of  links  on  a  document,  links  that  are  not  visible  to  other  users.  The  link 
service  needs  to  be  able  to  combine  different  sets  of  links  over  a  single  document  so  that 
a  user  perceives  them  as  forming  a  single  set.  Composites  can  be  supported  by 
appropriate  internal  recursion,  thus  permitting  composites  of  any  degree  of  nesting  to 
be  defined. 

3.1.3.  Inference 

The  inference  layer  provides  at  least  the  ability  to  traverse  a  link  and  retrieve  the 
node  at  the  destination.  It  is  also  a  reasonable  place  to  house  services  that  do  inference 
on  source  and  destination  nodes  in  conjunction  with  link  traversal  to  support 
generalized  link  traversal  as  defined  in  [BIEB89]. 

3.1.4.  Interface 

The  interface  layer  defines  the  mechanisms  through  which  the  user  interacts  with  the 
hyperbase,  and  is  responsible  for  displaying  the  information  contained  in  the  node. 


-205- 


3.2.  Programming  fesiies 

Object-oriented  programming  has  been  an  important  supporting  technology  for 
hypermedia,  and  the  development  of  standards  for  OOPS  will  facilitate  the  interaction 
of  various  hypermedia  systems. 

Some  systems,  such  as  HyperTies  [COGN89],  HyperPAD  [BRIG89],  and  HyperCard 
[WILL87|,  build  nodes  as  a  stack  of  different  objects,  A  typical  series  of  such  objects 
includes  the  background,  page,  field,  and  button.  If  nodes  are  to  be  accessed  through 
,  multiple  systems,  standardization  of  node  architecture  is  necessary. 

3.3,  Implementation  Standardization 

Implementation  standardization  is  necessary  if  hypermedia  systems  are  to  interoperate 
(for  instance,  by  accessing  the  same  information).  A  layered  architecture  offers  promise 
as  the  reference  model  for  such  standardization.  Outside  of  the  hypermedia  community, 
standardization  in  object-oriented  languages  and  environments  will  greatly  advance  the 
foundation  on  which  hypermedia  systems  rest. 

4.  interface  Issues 

There  are  two  main  categories  of  interface  issues  in  hypermedia:  those  concerned  with 
constructing  links  among  nodes,  and  those  concerned  with  browsing  a  completed 
network.  While  manj^  commercial  systems  include  facilities  for  generating  the  contents 
of  nodes,  this  process  is  so  application-dependent  that  it  seems  to  fall  outside  the  scope 

of  a  reference  model, 

4.1.  Building  Links 

Constructing  the  links  is  the  most  laborious  part  of  populating  a  hyperbase.  Three 
main  sets  of  techniques  are  commonly  used:  automatic,  mark-up  and  point-and-shoot. 

4.1.1.  Automatic  Linking 

Information  retrieval  (IR)  techniques  can  be  used  to  build  networks  automatically,  for 
example,  linking  together  all  (textual)  nodes  containing  a  specified  string  of  characters. 
Because  these  techniques  are  purely  syntactical  and  do  not  "understand**  the  text,  they 


-206- 


must  usually  be  supplemented  by  manual  review  and  revision  to  eliminate  spurious 
linkages  and  to  add  links  that  the  syntactical  scan  misses.  Natural  language  techniques 
from  AI  are  beginning  to  improve  the  effectiveness  of  automatic  linking,  but  still  are 
not  able  to  "understand"  a  text  and  so  cannot  completely  eliminate  manual 
editing. [HA YE88]  Applied  in  real  time,  these  techniques  are  a  common  way  to 
implement  virtual  links.  Standardization  of  IR  techniques  is  marginally  useful  for  the 
construction  of  links  before  run-time,  since  manual  editing  can  correct  any  errors,  but 
will  be  useful  when  these  techniques  implement  virtual  links,  to  insure  consistent 
operation  of  such  links  across  various  implementations. 

4.1.2.  Mark-Up  Linking 

Many  PC-based  systems  require  manual  mark-up  with  a  text  editor  to  identify  link 
sources  (and  sometimes  destinations).  The  most  simple  systems  simply  enclose  link 
anchors  in  reserved  brackets,  which  on  execution  are  interpreted  by  the  display  manager 
and  result  in  modified  display  attributes  for  the  anchor.  A  more  complex  mark-up 
system,  such  as  those  conforming  to  [IS086],  provides  a  rich  language  for  specifying 
functional  components  of  a  document,  such  as  paragraph  and  chapter  headers.  While 
these  mark-up  languages  are  not  originally  designed  for  hypermedia,  they  provide  a 
useful  mechanism  for  facilitating  automatic  linking. 

4.1.3.  Point-And-Shoot  Linking 

The  most  sophisticated  manual  linking  systems  (for  example,  [PEAR89])  use  a  point- 
and-shoot  interface  that  permits  the  user  to  point  at  the  entities  to  become  anchors  and 
thus  generate  links  directly. 

4.2.  Browsing 

Browsing  issues  include  the  form  and  manipulation  of  the  display,  and  navigational 
mechanisms. 


-207- 


4.2.1.  Display 

One  area  of  active  discussion  in  the  hypermedia  community  is  whether  information 
should  be  divided  into  screen-sized  chunks  or  "cards,"  or  whether  the  screen  should  be 
treated  as  a  window  that  moves  over  a  larger  unit  of  information.  There  appear  to  be 
applications  where  each  approach  is  superior,  and  both  should  be  accommodated  in  a 
reference  model. 

A  number  of  issues  concern  the  mechanics  of  manipulating  the  screen.  For  instance, 

»  In  a  scrolling  system,  does  one  push  the  window  up  over  the  information,  or 
does  one  push  the  information  up  past  the  window? 

•  How  does  one  select  a  link  origin? 

®  Hov/  are  active  and  inactive  buttons  represented  on  the  screen? 

•  What  is  the  correspondence  between  mouse  action  and  cursor  keys? 

The  Macintosh  has  provided  a  de  facto  standard  for  many  of  these  issues.  While 
standards  are  highly  desirable  (especially  for  users  who  must  move  from  one  platform  to 
another),  they  are  probably  best  handled  in  the  broader  CHI  community,  not  by 
hypermedia  specialists. 

4.2.2.  Navigational  Mechanisms 

Navigational  mechanisms  are  of  two  main  types:  maps  and  path  macros. 

4.2.3.  Maps 

A  map  is  a  single  display  that  shows  nodes  in  abbreviated  form  (often  as  icons)  and 
displays  the  links  among  them.  While  intuitive,  a  map  can  become  cluttered  and 
relatively  useless  for  large,  complex  systems  unless  it  is  selective.  For  instance,  a  map 
displaying  only  links  of  a  certain  type  and  their  associated  nodes,  or  only  composite 
nodes  and  not  their  components,  will  be  simpler  than  a  complete  map. 


-208- 


4.2.4.  Path  Macros 

A  path  macro  is  a  composite  that  is  generated  in  real  time  by  gathering  together 
nodes  that  the  user  has  visited  and  the  links  along  which  they  were  visited,  at  least  up 
to  some  limiting  topology.  For  instance,  a  linear  topology  is  commonly  used  to  generate 
a  backup  stack.  A  path  macro  permits  the  user  easily  to  revisit  nodes  that  have  been 
seen  and  are  of  particular  interest. 

4.3.  Interface  Standardization 

Interface  standardization  is  desirable,  especially  for  people  who  must  use  more  than 
one  platform  on  a  regular  basis.  Much  of  the  desired  standardization  here  will  come  not 
through  work  specifically  in  hypermedia,  but  through  broader  forums  in  CHI. 

5.  Conclusion 

Hypermedia,  especially  in  distributed  applications,  will  benefit  from  standardization. 
To  facilitate  developing  such  standards,  this  paper  has  suggested  a  high-level  reference 
model  that  describes  the  elements,  implementation  concerns,  and  interface  issues  for 
hypermedia.  In  the  area  of  elements,  the  greatest  need  for  standardization  is  in 
vocabulary.  Implementation  offers  a  rich  possibility  for  standardization  in  the 
development  of  a  layered  model  for  hypermedia,  and  will  profit  from  OOPS 
standardization  being  pursued  elsewhere.  Most  of  the  interface  standardization  that  is 
possible  at  this  point  is  being  pursued  in  the  broader  CHI  community,  and  (apart  from 
navigational  devices  that  are  particular  to  hypermedia)  should  not  be  the  focal  point  of 
standardization  efforts  by  the  hypermedia  community. 

References 

[BIEB89)  M.  Bieber  and  S.O.  Kimbrough,  "On  Generalizing  the  Concept  of 

Hypertext,"  Boston  College  Computer  Science  Department  Technical 
Report  BCCS-89-03,  1989. 

[BIEM89]  F.P.M.  Biemans,  "A  Reference  Model  for  Manufacturing  Planning 

and  Control,"  Ph.D.  Dissertation,  University  of  Twente,  1989. 

[BRIG89]  HyperPAD  Users  Guide,  Brightbill-Roberts  &  Co.,  Ltd.,  Syracuse, 

NY,  1989. 


-209- 


[CATL89] 


T.  Catlin,  P.  Bush,  and  N.  Yankelovich,  "InterNote:  Extending  a 
Hypermedia  Framework  to  Support  Annotative  Collaboration," 
Proceedings  of  Hypertext  '89,  365-378. 


[COGN89]  Hyperties  Author's  Guide,  Cognetics  Corporation,  Princeton  Jet.,  NJ, 

1989. 

[CONK87]  J.  Conklin  and  M.L.  Begeman,  "gIBIS:  A  Hypertext  Tool  for  Team 

Design  Deliberation,"  Proceedings  of  Hypertext  '87,  247-252. 

[DAY83]  J.    Day    and    H.    Zimmermann,    "The    OSI    Reference  Model," 

Proceedings  of  the  IEEE,  7  (December  1983),  1334-1340. 

[HALA87]  F.G.  Halasz,  "Reflections  on  NoteCards:  Seven  Issues  for  the  Next 

Generation  of  Hypermedia  Systems,"  Proceedings  of  Hypertext  '87, 
345-366. 


[HAYE88] 


[IS086] 

[PARU87] 

[PARU881 

[PARU89] 
[PEAR89] 
[SMOL87] 


P.  Hayes,  L.E.  Knecht,  and  M.J.  Cellio,  "A  News  Story 
Categorization  System,"  Proceedings  of  the  Association  for 
Computational  Linguistics  Conference  on  Applied  Natural  Language 
Processing,  1988. 

International  Standard  ISO  8879:  Information  processing  ~  Text 
and  office  systems  ~  Standard  Generalized  Markup  Language 
(SGML),  1986. 

H.V.D.  Parunak  and  J.F.  White,  "A  Synthesis  of  Factory  Reference 
Models,"  Proceedings  of  the  IEEE  Workshop  on  Languages  for 
Automation,  Vienna  (August  1987),  109-112. 

H.V.D.  Parunak  and  R.  Judd,  "LLAMA:  A  Layered  Logical 
Architecture  for  Material  Administration,"  International  Journal  of 
Computer  Integrated  Manufacturing  1:4  (1988),  222-233. 

H.V.D.  Parunak,  "Hypermedia  Topologies  and  User  Navigation," 
Proceedings  of  Hypertext  '89,  43-50. 

A.  Pearl,  "Sun's  Link  Service:  A  Protocol  for  Open  Linking," 
Proceedings  of  Hypertext  '89,  137-146. 

P.  Smolensky,  B.  Bell,  B.  Fox,  R.  King,  and  C.  Lewis,  "Constraint- 
Based  Hypertext  for  Argumentation,"  Proceedings  of  Hypertext  '87, 
215-246. 


-210- 


[STRE891 


N.A.  Streitz,  J.  Hannemann,  and  M.  Thuring,  "From  Ideas  and 
Arguments  to  Hyperdocuments:  Travelling  through  Activity  Spaces," 
Proceedings  of  Hypertext  '89,  343-364. 


[TOUL69] 


S.E.  Toulmin,  The  Uses  of  Argument,  Cambridge  University  Press, 
1969. 


[WILL87] 
[WILL891 


G.  Williams,  "HyperCard,"  Byte,  12:14  (December  1987). 

T.J.  Williams,  Editor,  A  Reference  Model  for  Computer  Integrated 
Manufacturing  (CIM),  Instrument  Society  of  America,  1989. 


[ZELL89] 


P.T.  Zellweger,  "Scripted  Documents:  A  Hypermedia  Path 
Mechanism,"  Proceedings  of  Hypertext  '89,  1-14. 


-211- 


An  Interchange  Format 
for  Hypertext  Systems: 
the  intermedia  Model 


Victor  A.  Riley 


Institute  for  Research  in  Information  and  Scfiolarship  (IRIS) 
Box  1946 
Brown  University 
Providence,  Rhode  Island  02912 


ABSTRACT 

I  Realization  of  the  potential  for  information  sharing 
that  is  inherent  in  hypertext  systems  depends  on  the 
ability  to  readily  exchange  data  between  those  sys- 
I  terns.  A  format  for  exchanging  link-related  data  be- 
]  tween  first-order  hypertext  systems  has  been  de- 
I  signed,   and   partially   implemented,   for  the 
;  Intermedia  system.  The  design  is  described  to  the 
i  individual  field  level.  An  example  of  usage  for 
Intermedia  link-related  information  is  provided. 
The  import,  export,  and  verification  utilities  cre- 
ated for  the  interchange  format  are  also  described. 

i  1.  INTRODUCTION 

I  The  concept  of  hypertext  has  been  around  for  several 
decades  and  recently  we  have  seen  the  advent  of 
||j  several  hypertext  applications  and  systems.  These 
i  applications  allow  one  to  create  text,  graphics,  ani- 
;  mation,  video,  and  a  number  of  other  data  types  and 
3  proceed  to  link  them  together  in  any  manner  one  sees 
j  fit.  One  capability  that  is  still  missing  is  the  abil- 
||  ity  to  transfer  a  set  of  hypertext  links  and  docu- 
ments from  one  system  to  another.  Such  a  capability 
1  would  open  the  door  to  sharing  information  and 
bring    us    one    step    closer    to    the  mythical 
i  "hyperspace"  or  "docuverse"  [NelsSl]  as  Nelson  has 
■  termed  it.  This  paper  examines  a  format  for  allow- 
I  ing  interchange  between  hypertext  systems. 

2.  PURPOSE  OF  THE  INTERCHANGE  FORMAT 

j  Although  a  wide  variety  of  hypertext/hypermedia 
'j  systems  exist  today,  they  can  be  placed  into  one  of 
two  categories. 

A  first-order  hypertext  system  manipulates  the  data 

'  of 

i    •  documents 


•  anchors  within  documents 

•  links  between  anchors 

•  some  standard  attributes  associated  with  docu- 
ments, anchors,  and  links.  (The  standard  at- 
tributes include  the  name,  creation  time,  and  cre- 
ator of  a  document,  anchor,  and  link.) 

Most  hypertext  systems  in  existence  today  are  at 
least  first-order  hypertext  systems  [Conk87]. 

A  second-order  hypertext  system  manipulates  all 
the  information  a  first-order  hypertext  system  con- 
tains with  the  additional  support  for 

•  user-defined  objects  and  types 

•  user-defined  attributes  and  keywords 

•  version  history  for  documents,  anchors,  links, 
and  attributes 

There  are  only  a  few  second-order  hypertext  systems 
in  existence  or  development  today:  Engelbart's 
NLS/ Augment  [Enge68],  Tektronix's  Hypertext  Ab- 
stract Machine  [Camp88],  and  Nelson's  Xanadu 
[Nels81]. 

Regardless  of  these  categories,  all  hypertext  sys- 
tems need  to  store  this  persistent  link  data  in  some 
form  of  database.  Since  database  formats  and  data- 
base files  are  inherently  nonportable,  a  portable  in- 
terchange format  must  be  designed  to  facilitate  ex- 
changing sets  of  link-related  hypertext  data  (what 
would  be  called  webs  in  Intermedia). 

Our  interchange  format  contains  the  essential  link- 
related  information  for  a  first-order  hypertext  sys- 
tem. Any  application  or  system  that  understands  the 
interchange  format — what  we  call  here  a  partici- 
pating application  or  system — can  capture  all  the 
existing  hypertext  link  information  as  it  exists  in 
some  other  participating  hypertext  system.  In  con- 
junction with  methods  for  converting  and  transferring 
document  data,  this  capability  makes  possible  the 
the  complete  sharing  of  information  between  hyper- 
text systems,  largely  fulfilling  the  "docuverse" 
ideal. 

The  interchange  format  is  useful  for  transferring 
data  between  similar  first-order  hypertext  systems. 
It  may  also  be  useful  for  transferring  first-order  hy- 
pertext information  into  a  second-order  hypertext 
system  or  vice-versa.  Suitable  defaults  could  be  sup- 
plied for  the  extra  information  necessary  to  trans- 
form first-order  information  into  second-order;  when 
transferring  second-order  information  into  firiit-order, 
the  extra  information  could  be  ignored. 

It  needs  to  be  stressed  that  the  application-specific 
contents  and  format  of  hypertext  documents  them- 


-213- 


selves  are  outside  the  scope  of  the  interchange  for- 
mat (which  is  concerned  with  the  links  between  the 
documents)  and  of  this  paper.  Data  exchange  on  the 
document  level  is  approached  in  other  ways,  com- 
monly bv  adherence  to  a  file  format  standard,  such 
as  PICT/TIFF,  MacPaint,  or  RTF. 

3.  THE  INTERCHANGE  FORMAT 

3.1  The  Basic  Objects 

The  information  that  most  hypertext  systems  deal 
with  is  basically  the  same,  although  the  names  of 
objects  may  differ  slightly  from  one  system  to  the 
next.  A  first-order  hypertext  system  deals  with  doc- 
uments, anchors,  links,  and  system  attributes.  These 
objects  are  stored  in  a  database  that  the  system's 
subordinate  applications  access  in  order  to  provide 
linking  functionality.  In  the  interchange  format, 
each  of  these  objects  corresponds  to  a  separate  data 
file  that  contains  the  information  specific  to  all  oc- 
currences of  that  object  in  the  system.  The  architec- 
ture of  these  files  is  described  in  the  next  section. 

Documents  are  the  containers  for  the  application- 
specific  information  in  the  hypertext  system.  They 
are  built  up  of  two  components:  the  actual  applica- 
tion-specific contents  of  the  document  (the  informa- 
tion the  user  is  interested  in  working  with),  and  the 
information  necessary  for  the  application  to  render 
its  views.  The  contents  could  be  in  the  form  of  text, 
graphics,  audio,  video,  etc. 

Anchors  are  the  locations  in  documents  to  which 
links  are  attached.  Some  examples  of  anchors  are 
spans  of  text,  graphical  objects,  audio  or  video,  or 
bitmaps.  Anchors  are  application-specific  in  that  it 
is  the  application,  not  the  hypertext  system's 
database,  that  must  render  the  anchor  (e.g.,  in  doc- 
ument views). 

Links  are  the  connections  between  anchors.  They  are 
directional  in  that  they  have  a  source  and  destina- 
tion anchor.  Applications  can  enforce  bidirectional- 
ity  or  directionality  by  giving  equal  precedence  to 
both  source  and  destination,  or  keeping  the  distinc- 
tion. 

System  attributes  are  predefined  attributes  that  are 
associated  with  documents,  anchors,  and  links.  For 
all  first-order  hypertext  sj^stems,  these  consist  of 
the  name,  creator,  and  creation  time.  Intermedia 
adds  the  modifier  and  last  modification  time  to  the 
standard  system  attributes. 

User-defined  attributes  are  also  associated  with 
documents,  anchors,  and  links.  They  allow  for  flexi- 
ble processing  and  retrieval  of  hypertext  informa- 
tion. 


3.2  Architecture  of  the  Data  Files 

The  interchange  format  consists  of  five  data  files  for 
recording  information  about  the  link-related  objects 
in  the  participating  hypertext  system,  and  one  file 
for  each  document  in  the  hypertext  system. 

document  information /i7e 

The  document  information  file  contains  general  in- 
formation dealing  with  all  hypertext  documents 
stored  in  the  participating  system.  This  information 
allows  an  application  to  gain  access  to  the  physical 
location  of  a  document,  get  the  user-defined  access 
rights  associated  with  the  document,  and  retrieve 
information  about  the  creator  and  last  modifier  of 
the  document.  A  unique  identifier  for  the  document 
enables  access  to  anchor  information  stored  in  the 
anchor  file  (described  below). 

anchor  file 

The  anchor  file  contains  information  about  all  an- 
chors in  all  documents  in  the  hypertext  system.  This 
information  allows  an  application  to  know  where  an 
anchor  is  located,  who  created  and  last  modified 
the  anchor,  and  other  information  that  may  be 
needed  (e.g.,  to  render  a  view  of  the  anchor).  A 
unique  identifier  for  the  anchor  enables  access  to 
link  information  stored  in  the  link  file  (described 
below). 

link  file 

The  link  file  contains  information  about  all  links  be- 
tween all  anchors  in  the  hypertext  system.  This  in- 
formation allows  the  system  to  traverse  hypertext 
links.  The  file  also  contains  information  about  the 
creator  and  last  modifier  of  the  link.  A  name  and 
unique  identifier  for  the  link  are  provided,  for  con- 
sistency with  the  other  files,  and  to  allow  for  future 
expansion  of  functionality. 

attribute  definition  file 

The  attribute  definition  file  contains  information 
defining  the  attributes  and  keywords  used  in  the 
system.  Predefined  (system)  attributes  such  as  name, 
creator,  modifier,  creation  time  and  modification 
time,  are  not  defined  in  this  file. 

attribute  file 

The  attribute  file  contains  information  about  which 
objects  have  which  attributes  attached  to  them,  as 
well  as  the  values  of  those  attributes. 


-214- 


document //7es 

The  format  of  each  document  file  is  determined  by 
its  contents,  and  the  requirements  of  the  participat- 
ing application  in  which  it  is  used.  Formats  cur- 
rently employed  in  Intermedia  include  "web,"  for- 
matted text,  structured  graphics,,  timeline,  and 
bitmap  image.  As  noted  above,  the  exchange  of  this 
information  between  systems  is  not  intended  to  be 
part  of  the  interchange  format.  However,  several 
fields  in  the  five  link-related  files  are  indirectly 
dependent  on  the  existence,  system  attributes,  or  con- 
tents of  the  document  files.  These  are  described  un- 
der "Implementation." 

3,3  Impiementation 

This  section  describes  the  interchange  format  at  the 
level  of  data  formatting  and  field  definition. 
Examples  illustrating  these  descriptions  are  pro- 
vided in  Section  4. 

Data  Formatting 

In  order  to  make  the  interchange  process  as  straight- 
forward as  possible,  the  format  of  the  data  to  be  ex- 
changed is  kept  simple 

Each  value  is  stored  in  normal  ASCII  format,  so 
that  it  is  easily  readable,  editable,  and  portable. 

Each  data  record  in  a  file  is  delimited  by  a  car- 
riage-return/linefeed character  pair.  Each  data 
field  in  a  record  is  delimiled  by  a  tab  character.  To 
avoid  conflicts,  the  tab  character  is  not  permitted  in 
document  and  path  names. 

Data  values  are  either  strings  or  numbers.  String 
values  can  be  any  length.  Numeric  values  are  four 
full  bytes;  the  decimal  ASCII  digits  correspond  to  an 
unsigned  32-bit  long  word.  Certain  numeric  fields 
store  information  in  terms  of  the  bit  patterns  in  the 
long  woi'd. 

All  numeric  values  that  denote  a  time  are  stored  in 
Unix  GMT  format,  which  expresses  a  time  value  as 
the  number  of  "ticks"  since  an  established  starting 
point  (midnight  of  January  1,  1970).  There  are  about 
31.5  million  ticks  in  a  calendar  year. 

Values  for  the  predefined  system  attributes 
{creationTime,  modTime,  creator,  modifier,  and 
name)  are  obtained  from  the  operating  system  via 
the  Export  udlity. 

Since  some  applications  may  require  data  not  specif- 
ically identified  in  the  interchange  format,  certain 
fields  are  allotted  for  this  special  purpose.  Data  in 
these  fields  is  arbitrarily  stored  in  string  format,  for 
maximum  flexibility,  and  may  need  to  be  converted 


to  some  other  data  format  for  use  by  a  target  appli- 
cation. This  feature  allows  for  a  variable  number  of 
data  values  and  types  to  be  transferred  by  the  inter- 
change format. 

Site  Identification 

The  first  field  of  each  record  contains  a  site-specific 
ID.  This  value  is  composed  of  a  unique  number  for 
each  site  (or  machine)  using  the  interchange  format 
and  a  site  unique  number  for  the  database  to  which 
hypertext  data  is  being  imported  or  exported.  The 
combination  of  a  sitclD  (with  its  "site"  and 
"database"  components)  and  an  object's  own  unique 
ID  allows  the  object  to  permanently  maintain  its 
identity  across  exchanges  of  data  between  sites. 

Some  type  of  assignment  of  unique  numbers  for  sites 
must  be  administered  in  order  to  implement  this  fea- 
ture fully.  If  this  were  not  done,  however,  the  re- 
mainder of  the  interchange  format  could  still  be  im- 
plemented independently. 

Another  uniqueness  scheme  might  consist  of  combin- 
ing a  32-bit  random  number  with  two  16-bit  random 
numbers,  which  would  provide  IDs  for  the  site  and 
the  local  database,  respectively.  This  64-bit  number 
should  be  unique  across  the  domain  of  all  hypertext 
systems. 

Field  Definitions 

document  information  file  fields 

sitelD  (Numeric)  Unique  identifier  of  the 

originating  site  and  database.^ 

docID  (Numeric)  Unique  identifier  of  a 

document.  Assigned  sequentially  by 
the  DBMS. 

docType  (Numeric)  Code  specifying  the 

document's  type. 

Allows  the  system  to  identify  the 
the  correct  target  application  for 
application-specific  data.^ 


^The  first  short  word  of  the  value  stores  the  site  number;  the 
second  short  word  stores  the  database  number.  The  interchange 
format  stores  the  number  resulting  from  reading  the  two  short 
words  as  a  long  word. 

^Intermedia  supplies  codes  for  its  currently  supported  document 
types  (InterWord,  InterDraw,  etc.).  Codes  must  be  standardized 
for  participating  systems,  be  these  numeric  codes  or  string  codes. 


-215- 


accessRights  (Numeric)  Number  expressing  the 
types  of  access  allov/ed  to  the  doc- 
ument for  various  groups  of  users.^ 

groupNarne  (String)  The  name  of  the  group 
identified  in  accessRights. 

creationTime  (Numeric)  Time  the  document  was 
created, 

modTime  (Numeric)  Time  the  document  was 

modified. 

creator  (String)  Name  of  the  user  that 

created  the  document. 

modifier  (String)  Name  of  the  last  user  to 

modify  the  document. 

docName  (String)  Name  of  the  document. 

Assigned  by  user  when  document  is 
saved. 

path  (String)  Directory  location  of  the 

document  in  the  Unix  tree,  relative 
to  the  application's  home  direc- 
tory. 


anchor  file  fields 

siteJD 


(See  description  for  document  in- 
formation file.) 


anchorlD  (Numeric)  Unique  identifier  of  an 

anchor;  assigned  sequentially  by 
the  DBMS. 

anchorDocID  (Numeric)  Value  of  docID,  in  the 
document  information  file,  for  the 
document  containing  the  anchor 
identified  by  anchorlD. 

Allows  system  to  determine  the 
document  in  which  the  anchor  is 
located. 

creationTime  (Numeric)  Time  the  anchor  was 
created. 


modTime  (Numeric)  Time  the  anchor  was 

modified. 

creator  (String)  Name  of  the  user  that 

created  the  anchor. 

modifier  (String)  Name  of  the  last  user  to 

modify  the  anchor. 

anchorName     (String)  Name  of  the  anchor. 

X-loc  (Numeric)  X,  Y,  and  Z-axis  coordi- 

nates of  the  anchor,  within  the 
document  specified  by  docID. 

Y-loc  These  allow  system  to  determine 

placement  of  anchor  in  document 
window. 

Z-loc  Interpretation  of  coordinates  is 

application-specific. 

appData  (String)  Application-specific  infor- 

mation dealing  with  anchors. 

Allows  participating  application 
to  obtain  other  information  re- 
quired. Exam.ples  might  include 
data  needed  to  render  a  type  of 
window  view. 

Values  are  separated  by  space 
characters,  or  other  delimiters 
specified  by  the  participating  ap- 
plication. 


link  file  fields 

sitelD 

linkID 
linkType 


(See  description  for  document  in- 
formation file.) 

(Numeric)  Unique  identifier  of  a 
link;  assigned  sequentially  by  the 
DBMS. 

(Numeric)  Code  specifying  the  type 
of  relationship  between  the  link's 
two  anchors.  ^ 


^  The  four  bytes  of  the  value,  from  high  to  low,  correspond  to  the 
rights  granted  to:  system  administrator,  owner,  group,  and  world 
(all)  users.  The  bits  of  each  byte,  from  high  to  low,  correspond  to 
the  following  rights  granted  to  each  of  the  four  user  groups: 
change  access  rights  for  the  document,  write  to  the  document, 
create  links  in  the  document,  and  view  the  document.  The  bits  are 
set  on  or  off  in  groups  of  two. 


srcAnchorlD  (Numeric)  Source  anchor  of.  the 
link,  as  identified  by  the  value  of 
anchorlD,  in  the  anchor  file. 


intermedia  supplies  codes  for  its  currently  supported  document 
link  types.  Codes  must  be  standardized  for  participating  systems, 
be  these  numeric  codes  or  string  codes. 


-216- 


destAnchorlD  (Numeric)  Destination  anchor  of 
the  link,  as  identified  by  the  value 
of  anchorlD,  in  the  anchor  file. 

creationTime  (Numeric)  Time  the  link  was  cre- 
ated. 

modTime  (Numeric)  Time  the  link  was  modi- 

fied. 

creator  (String)  Name  of  the  user  that 

created  the  link. 

modifier  (String)  Name  of  the  last  user  to 

modify  the  link. 

linkName         (String)  Name  of  the  link. 

attribute  definition  file  fields 

sitelD  (See  description  for  document  in- 

formation file.) 

attDefID  (Numeric)  Unique  identifier  of  an 

attribute  definition;  assigned  se- 
quentially by  the  DBMS. 

attDefType       (Numeric)  Code  specifying  the  at- 
tribute's type.  ^ 

General-purpose  flag  value.  One 
potential  use  is  to  specify  what 
objects  the  attribute  can  be  at- 
tached to. 

attName  (String)  Name  of  the  attribute. 

attribute  file  fields 

sitelD  (See  description  for  document  in- 

formation file.) 

attDefID  (Numeric)  Value  of  attDefID,  in 

the  attribute  definition  file. 

Allows  system  to  look  up  the  at- 
tribute's name  and  type. 


attValType 
attValue 


objectType 

objSitelD 

objectID 


This  section 
can  be  used 
data  from  a 
Intermedia. 


(Numeric)  Code  specifying  the 
data  format  of  attValue.'^ 

(Variable  format)  Value  of  the  at- 
tribute. Assigned  by  the  user. 

The  next  three  fields  refer  to  the 
object  to  which  the  attribute  is  at- 
tached: (document,  anchor,  or 
link). 

(Numeric)  Code  specifying  the  ob- 
ject type  (document,  anchor,  or 
link).  3 

(Numeric)  Value  of  sitelD,  in  the 
corresponding  file  {document  in- 
formation, anchor,  or  link). 

(Numeric)  Value  of  the  object's  ID, 
in  the  corresponding  file  (document 
information,  anchor,  or  link). 

4.  EXAMPLE  OF  USE 

illustrates  how  the  interchange  format 
to  create,  store,  and  reuse  link-related 
first-order  liypertext  system,  namely 


4.1.  Sample  Data  in  Intermedia 


The  Intermedia  system  is  described  in  a  number  of 
articles,  notably  [Meyr86]  and  [Yank88a].  A  public 
release  of  the  software,  with  full  documentation,  is 
also  currently  available  through  IRIS  and  through 
the  Apple  Programmer  and  Developer's  Association 
(APDA).  This  release  (3.0)  runs  on  the  Apple 
Macintosh  II,  under  version  1.1  of  A/UX,  Apple's 
version  of  Unix. 

Figure  1  shows  the  Intermedia  desktop  environment. 
Two  elementary  sample  documents  have  been  cre- 
ated, one  in  Iiitermedia's  InterWord  format,  the 
other  in  InterDraw.  For  the  clarity  of  the  example, 
these  objects  have  been  created  in  an  empty  new 
Intermedia  database.  The  folder  window  (labelled 
"/int/docs/demo")  contains  the  icons  representing 
the  documents  and  the  Web  comprising  the  links  be- 
tween them.  The  Web  View  window  displays  the 
linking  structure.  The  information  used  in  generating 


participating  system  supplies  codes  for  its  currently  ^A  participating  system  supplies  codes  for  its  currently 
supported  attribute  definition  types.  Codes  must  be  standardized  supported  attribute  value  types.  Codes  must  be  standardized  for 
for  participating  systems,  be  these  numeric  codes  or  string  codes,     participating  systems,  be  these  numeric  codes  or  string  codes. 

^A  participating  system  supplies  codes  for  the  object  types  of 
document,  anchor,  and  link.  Codes  must  be  standardized  for 
participating  systems,  be  these  numeric  codes  or  string  codes. 


-217- 


this  Web  View  is  also  used  to  generate  the  anchor 
and  link  files  of  the  interchange  format. 

An  anchor  has  been  created  from  the  word  "block"  in 
the  InterWord  document  (indicated  by  the  arrow 
marker  over  the  word).  Another  anchor  has  been 
created  from  the  two  rectangles  in  the  InterDraw 
document.  Each  anchor  can  be  assigned  a  name;  the 
names  are  not  shown  here,  but  can  be  viewed  and 
edited  by  the  user  by  means  of  dialog  boxes. 


The  current  version  of  Intermedia  does  not  make  use 
of  attributes  and  keywords,  so  these  are  not  repre- 
sented in  the  example. 

At  the  moment  shown  in  the  figure,  the  link  be- 
tween the  two  anchors  has  just  been  followed,  from 
the  InterWord  to  the  InterDraw  document.  This  is 
shown  by  the  shaded  selection  handles  around  the 
rectangles  and  the  shaded  link  line  in  the  Web 
View. 


^    File    Edit    Intermedia    VnnX    Arrange  Print 


Figurel.  Sample  documents  on  the  Intermedia  desktop.  Linking  is  indicated  by  the  arrow  markers  in  the  doc- 
ument windows  and  the  icon-connecting  line  in  the  Web  View  window. 


Intermedia  allows  users  to  edit  the  access  rights  to 
documents,  through  the  use  of  the  "Document 
Properties"  dialog  box  (simple  matrix  of  sixteen 
check  boxes,  not  shown  here).  The  ability  to  edit 
these  rights  is  itself  controlled  by  the  rights 
scheme,  with  the  system  administrator  having  ul- 
timate control  over  a  document's  access.  The  rights 
for  the  two  documents  in  this  example  are  set  so  as 
to  grant  the  system  administrator,  document  owner, 
and  members  of  the  owner's  "group"  the  right  to  per- 
form all  operations  on  these  documents;  all  other 
users  (the  "world")  can  only  read  them  and  make 
links  in  them. 


4.2.  Sample  Data  in  the  Interchange  Format 

This  section  illustrates  how  a  current  version  of  the 
interchange  format  stores  the  first-order  hypertext 
link  information  embodied  in  the  sample  Intermedia 
environment  in  Figure  1. 

After  creation  of  the  documents,  anchors,  and  links 
in  Intermedia,  the  link-related  information  stored  in 
the  Intermedia  database  is  converted  into  the  inter- 
change format  by  use  of  the  Export  utility,  which  is 
described  in  Section  5. 


-218- 


The  ASCII  data  values  resulting  from  this  conver- 
sion are  shown  in  the  following  tables,  as  they 
would  appear  when  viewed  in  a  text  editor  (minus 
their  field  and  record  delimiter  characters).  These 
values  fully  describe  the  anchor,  link,  and  document- 
properties  information  contained  in  the  Intermedia 
database  for  the  documents  depicted  in  Figure  1. 

It  is  arbitrarily  assumed  that  the  ID  numbers  for 
both  the  current  site  and  converted  database  arel. 
Using  the  rule  for  generating  the  value  of  the 
SitelD  field  noted  under  "Implementation,"  the  fol- 
lowing long  word  is  stored: 

00000000     00000001     00000000  00000001 
site  number      database  number 

This  is  displayed  as  the  number  65537.  Note  that 
this  value  is  the  same  for  every  data  record  in  the 
example. 

document  info  file 


11111111 
system 


11111111 
owner 


11111111 
group 


00001111 
world 


Using  the  rule  noted  under  "Implementation,"  system 
administrator,  owner,  and  "group"  users  can  perform 
all  operations  on  these  documents;  "world"  users  can 
only  read  them  and  make  links  in  them. 

The  groupName  of  the  group  referred  to  in  the  ac- 
cessRights  is  "iris".  The  creator  and  modifier  fields 
contain  the  user  ID  of  the  author  of  this  example: 
"var". 

The  creationTime,  expressed  in  Unix  GMT  format  as 
"604771573,"  is  Wednesday,  March  1,  1989, 
4:06:13  PM. 

The  docName  values  of  the  two  documents  are  those 
shown  in  the  documents'  windows  in  Figure  1.  The 
relative  path  name  of  the  document  files  is  that 
shown  in  the  folder  window  in  Figure  1. 


anchor  file 

Field 

Value 

Value 

r  lelCl 

Vain  o 
V  alUc 

V  dlUc 

sit  eld 

65537 

65537 

sitelD 

65537 

65537 

docID 

1 

2 

anchorlD 

1 

2 

docType 

300 

301 

anchorDocID 

1 

2 

accessRights 

4294967055 

4294967055 

creationTime 

604771726 

604771729 

groupName 

iris 

iris 

modTime 

604771726 

604771729 

creationTime 

604771573 

604771642 

creator 

var 

var 

modTime 

604771573 

604771642 

modifier 

var 

var 

creator 

var 

var 

anchorName 

Source 

Destination  An 

modifier 

var 

var 

Anchor 

chor 

docName 

wordDoc 

drawDoc 

X-loc 

40 

23 

path 

demo 

demo 

Y-loc 

45 

28 

The  documents  in  the  example 

were  the  first  created 

Z-loc 

0 

0 

in  the  Intermedia  database,  so 

their  docID  numbers 

are  "1"  and  "2". 

appData 

1 

1203 

The  docType  uses  Intermedia  type  codes:  "300"  for 
InterWord,  "301"  for  InterDraw. 

The  accessRights  are  stored  in  the  bit  pattern  of  the 
value's  long  word.  The  value  for  the  documents  in 
this  is  written  in  ASCII  as  "4294967055,"  which  is 
equivalent  to  the  bits: 


The  anchors  in  the  example  were  the  first  created  in 
the  Intermedia  database,  so  their  anchorlD  numbers 
are  "\"  and  "2" .  Their  anchorDocID  values  identify 
the  documents  they  were  created  in:  "1"  (the 
InterWord  document)  and  "2"  (the  InterDraw  docu- 
ment), respectively. 


-219- 


The  anchorNames  of  the  anchors  are  "Source 
Anchor"  and  "Destination  Anchor".  These  names  are 
informational;  they  do  not  affect  the  directionahty 
of  the  hnk. 

The  X,  Y,  and  Z  coordinates  for  each  anchor,  and 
the  values  in  the  appData  field,  are  interpreted  by 
the  applications  associated  with  the  documents 
identified  in  the  anchorDoclD  field  (InterWord  and 
InterDraw),  in  ways  dependent  upon  the  document 
contents.  For  instance,  the  data  value  for  anchor  1 
specifies  the  "anchor  type,"  while  the  values  for 
anchor  2  specify:  the  two  objects  the  anchor  is  con- 
nected to,  the  "view  index"  of  the  anchor,  and  the 
"mark  type"  (these  terms  are  included  for  illustra- 
tion; their  definition  is  outside  the  scope  of  this  pa- 
per). Other  link-related  data  values  that  do  not  fit 
elsewhere  in  the  architecture  of  the  interchange 
format  can  be  recorded  here  in  similar  fashion. 


link  file 
Field 

sitelD 
linkID 


Value 
65537 
1 


The  linkName  of  the  link  is  "Demo  Link".  This 
value  is  not  presently  used  in  Intermedia,  but  is 
stored  for  consistency,  in  the  event  it  is  needed  for  a 
future  version  of  Intermedia,  or  for  another  partici- 
pating system. 

There  are  a  number  of  other  fields  in  the  inter- 
change format  that  are  used  this  way,  providing 
flexibility  beyond  the  bare  needs  of  Intermedia  it- 
self. SitelD,  and  the  creationTime,  modTime,  cre- 
ator, and  modifier  fields  in  the  anchor  and  link 
files  are  examples. 

attribute  definition  and  attribute  files 

Although  attributes  were  not  included  in  this 
Intermedia  example,  their  use  in  this  context  can  be 
illustrated  hypothetically. 

For  instance,  in  order  to  support  optional  unidirec- 
tional linking,  an  attribute  with  the  attName  of 
"anchorType"  could  be  entered  in  the  attribute  defi- 
nition file.  Codes  for  "source"  and  "destination" 
could  then  be  entered  as  values  for  attValue  in  the 
attribute  file,  and  attached  to  particular  anchors  by 
making  the  requisite  entries  for  objectType  and  objec- 
tlD. 


linkType 

srcAnchorlD 

destAnchorlD 

creationTime 

modTime 

creator 

modifier 

linkName 


2 
1 
2 

604771731 
604771731 
var 
var 

Demo  Link 


The  link  between  the  anchors  in  the  two  documents 
in  the  example  was  the  first  created  in  the 
Intermedia  database,  so  its  linkID  number  is  "1". 


The  linkType  uses  Intermedia  type  codes: 
notes  a  "reference"  link. 


'2"  de- 


The  "source"  anchor  of  the  link  is  the  one  identified 
in  the  anchor  file  by  the  anchorlD  of  "1";  conse- 
quently "I"  is  stored  here  for  srcAnchorlD.  The 
"destination"  anchor  of  the  link  is  treated  in  paral- 
lel fashion.  Keep  in  mind  that  linking  in  Intermedia 
is  bidirectional;  the  distinction  between  source  and 
destination  is  maintained  for  participating  systems 
that  distinguish  between  the  two. 


Another  significant  use  of  user-defined  attributes  is 
for  filtering  of  hypertext  information  based  on  key- 
words, which  are  text  strings  attached  by  the  user 
to  hypertext  objects.  Keywords  serve  as  flags  for  as- 
sociating objects  with  each  other.  Typical  keywords 
might  be  "Modernism,"  "Mitosis,"  "Moon,"  or 
"Manichean."  Keywords  can  be  implemented  by 
defining  an  attribute  named  "Keyword"  and  allow- 
ing users  to  enter  their  keywords  as  values  for  the 
attribute. 

document  files 

The  operating  system  files  that  store  the  contents  of 
the  Intermedia  documents  shown  in  Figure  1  are  lo- 
cated in  the  directory  identified  in  the  path  field 
of  the  interchange  format's  document  information 
file.  The  names  of  the  document  files  are  stored  in 
the  docName  field  of  the  same  interchange  format 
file. 

As  noted  in  Section  2,  the  application-specific  con- 
tents and  format  of  the  document  files  are  not  con- 
sidered part  of  the  interchange  format.  In  order  to 
support  such  exchange  of  document  information. 
Intermedia  provides  various  methods  for  importing 
and  exporting  document  content  data.  These  methods 
include  the  use  of  standard  file  formats,  such  as  RTF 
(for  InterWord  documents),  PICT  (for  InterDraw  doc- 
uments), and  TIFF  or  MacPaint  (for  InterPix  bitmap 
images). 


-220- 


4.3.  Other  Intermedia  Usage  of  the  Interchange  Format 

An  early  version  of  the  interchange  format  has  al- 
ready been  used  in  the  suite  of  "Webware"  products 
making  up  part  of  the  public  release  version  of 
Intermedia.  The  procedure  for  installing  the  webs 
for  "Exploring  the  Moon"  and  the  Intermedia 
Tutorials  into  the  Intermedia  link  server  database 
involves  running  a  script  that  calls  the  Import  util- 
ity, which  transfers  web  data  in  the  interchange 
format  from  a  floppy  disk  to  the  Intermedia  server 
hard  disk.  The  Import  utility  is  described  in  Section 
5  of  this  paper. 

This  early  prototype  of  the  interchange  format  does 
not  support  attributes  or  SitelDs,  and  the  storage  for 
anchors  is  tailored  to  their  treatment  within 
Intermedia. 

5.  UTILITIES  FOR  THE  INTERCHANGE  FORMAT 

A  number  of  utilities  have  been  created  for  use  with 
the  interchange  format.  Some  of  the  utilities  process 
the  data  of  the  interchange  format  to  validate  the 
data,  others  are  used  in  conjunction  with  the  the 
Intermedia  Link  Protocol  Server  ("the  link  server") 
to  import  and  export  data  into  the  Intermedia 
database. 

5.1.  Verify 

The  Verify  utility  checks  the  consistency  of  the  in- 
terchange format  files.  It  ensures  that  all  documents 
exist  for  all  anchors,  and  that  all  anchors  exist  for 
all  links.  If  keywords  are  implemented,  the  utility 
ensures  that  all  documents,  anchors,  and  links  exist 
for  all  keywords.  A  series  of  hash  tables  is  used 
during  the  checking  process.  If  any  ID  is  not  in  the 
hash  table,  the  object  being  processed  is  removed 
and  placed  in  an  error  file,  and  the  user  is  informed. 

5.2.  Export  and  Import 

The  Export  and  Import  utilities  are  used  to  extract 
and  store,  respectively,  the  data  from  Intermedia's 
database  using  the  link  server. 

Earlier  prototypes  of  these  two  utilities  were  help- 
ful in  the  conversion  of  our  Intermedia  databases 
when  we  exchanged  Ingres  for  the  Intermedia  link 
server  and  its  new  database  system  based  on  C-Tree 
[Fair88].  The  utilities  have  also  helped  us  convert 
databases  from  one  data  dictionary  format  to  an- 
other, by  running  Export  with  an  old-format  server, 
and  Import  with  a  new-format  server. 

The  Import  utility  reads  the  files  of  the  interchange 
format  and  calls  the  import  functions  of  the  link 
server  to  add  the  data  to  the  database.  One  param- 
eter to  the  utility  specifies  whether  to  create  new 
IDs  for  each  object  being  added  to  the  database  or  to 


reuse  the  existing  object  IDs.  This  feature  allows  us 
to  either  append  data  to  the  end  of  the  database 
(with  new  IDs),  or  replace  the  data  in  the  database 
with  new  data  (having  the  IDs  of  the  existing  ob- 
jects). Using  the  "replace"  feature  we  are  able  to 
change  the  location  of  the  document  tree  without 
having  to  change  the  IDs  for  the  documents.  The 
other  parameters  to  the  utility  specify  the  Unix  file 
system  locations  for  the  location  to  read  the  inter- 
change format  from,  the  name  of  the  database  to 
add  the  data  to,  and  the  new  location  for  the  docu- 
ment tree. 

The  Export  utility  caV.'j.  the  export  functions  of  the 
link  server  to  dump  all  data  from  the  database  into 
the  interchange  format.  The  Verify  utility  can  be 
run  in  conjunction  with  Export,  to  ensure  data  in- 
tegrity. The  parameters  of  Export  are  the  same  as 
those  of  Import  that  deal  with  Unix  file  specifica- 
tions, except  that  Export  writes  where  Import  reads, 
and  vice  versa. 

5.3.  Future  Developments  for  Utilities 

The  utilities  described  here  have  been  integrated 
into  an  application  that  will  potentially  be  in  a 
publicly  available  version  of  Intermedia.  This  ap- 
plication, called  Transfer,  enables  users  to  select 
document,  anchor,  and  link  information  to  be  ex- 
ported by  selecting  folders  and  their  contents  (i.e., 
documents  and  webs).  In  order  to  maintain  the  in- 
tegrity of  all  the  webs  in  the  selection,  documents 
that  lie  outside  the  selection  in  the  folder  hierar- 
chy, but  have  links  or  anchors  in  a  selected  web,  are 
also  exported.  When  exporting,  the  user  can  select 
the  type  of  media  to  export  the  data  to.  Hard  disk, 
floppy  diskette,  and  tape  are  currently  supported. 
Users  can  also  import  previously  exported  data, 
from  the  same  media  types. 

At  present,  the  Transfer  application  generates  data 
in  a  form  of  the  interchange  format  described  here. 
It  is  intended  that  the  application  be  able  to  gener- 
ate any  of  a  number  of  other  formats  as  their  defini- 
tion and  use  becomes  available. 

There  are  also  plans  to  create  other  utilities  to  en- 
able the  conversion  of  first-order  interchange  for- 
mats into  second-order  interchange  formats,  or  from 
prototype  first-order  interchange  formats  into  pro- 
duction first-order  interchange  formats,  as  their 
needs  arise. 

6.  OTHER  INTERCHANGE  FORMATS 

At  the  time  I  developed  the  interchange  format  de- 
scribed here,  I  knew  of  no  other  hypertext  inter- 
change formats  under  development.  Many  design 
elements  in  this  interchange  format  apply  specifi- 
cally to  the  requirements  of  the  Intermedia  system. 


-221- 


However,  the  major  conceptual  elements  are  common 
to  most  other  hypertext  interchange  formats. 

In  this  described  interchange  format,  the  structure  of 
the  data  file  is  static,  while  the  the  data  that  fills 
that  structure  changes  dynamically.  A  format  like 
this  is  very  simple  to  implement.  Hov/ever,  when 
interchanging  with  other  disparate  systems  this  in- 
terchange format  becomes  very  difficult  to  use. 
Converting  its  structure  to  a  tagged  format,  like 
SGML,  would  make  it  more  portable. 

It  should  be  possible  to  ceo  vert  this  format  to  the 
X3V1.8M  interchange  format  [Gold89]  with  rela- 
tively few  or  no  extensions  to  the  HyTime  DTD. 
However,  there  are  several  drawbacks  in  doing  this. 
First,  none  of  the  documents  in  Intermedia  are  stored 
in  SGML  format,  so  references  to  components  of  the 
documents  may  be  difficult.  Second,  the  link-and-an- 
chor  database  is  separate  from  the  document 
database,  in  order  to  support  linking  to  non-writable 
media  (like  CD-ROM  disks)  and  to  support  multiple 
Vt^-eb  mappings  over  the  same  document  sets. 

The  task  of  converting  this  data  structure  to  support 
any  of  the  interchange  formats  [Born89]  that  conform 
_  to  the  Dexter  model  [Hala89]  would  be  possible  as 
well.  This  would  require  adding  tags  and  attributes 
the  the  existing  data  elements  with  some  minor  re- 
organizations. This  is  planned  as  a  future  project. 

6.  SUMMARY 

In  this  paper  a  format  is  documented,  that  shows  the 
structure  of  the  data  files  and  the  minimum  infor- 
mation necessary  to  transfer  hypertext  information 
from  one  first-order  hypertext  system  to  another. 
These  data  files,  when  combined  with  a  methodol- 
ogy for  converting  and  transferring  the  contents  of 
application  document  files,  embody  an  interchange 
format  enabling  the  full  exchange  of  information  be- 
tween existing  hypertext  systems.  This  was  demon- 
strated by  the  use  of  the  interchange  format  to 
transfer  data  into  and  out  of  Intermedia. 

It  is  hoped  that  this  format  could  be  a  base  of  ideas 
in  developing  an  interchange  standard  for  first-order 
hypertext  systems  thus  enabling  the  sharing  of  hy- 
pertext information  more  freely. 

The  need  remains  to  establish  and  publish  conven- 
tions for  assigning  values  in  the  SitelD,  docType, 
linkType,  attDeffype,  attValType,  and  objectType 
fields,  to  insure  compatibility  between  the  systems 
on  both  ends  of  a  data  exchange. 


8.  ACKNOWLEDGEMENTS 

I  wish  to  thank  everyone  at  IRIS  for  their  help  dur- 
ing the  writing  of  this  paper,  especially  Jim  Coombs 
and  Norm  Meyrowitz  for  being  the  best  sounding 
boards  for  my  ideas,  and  Mark  Saw  telle  for  assis- 
tance in  preparing  the  text. 

REFERENCES 

[Born89j  J.  Bornstein,  "Hypertext  Interchange  Format- 
Discussion  and  Format  Specification—DRAFT  1,3.3", 
September  1989.  Available  from  author. 

[Camp88]  B.  Campbell,  J.  Goodman,  "HAM:  A  General  Purpose 
Hypertext  Abstract  Machine,"  Communications  of  the 
/ACM,31(7):856-861,  1988. 

[Conk87j  J.  Conklin,  "Hypertext:  An  Introduction  and  Survey," 
IEEE  Computer,  20(9):17-41,  1987. 

[Enge68j  D.  Englebart,  W.  English,  "A  Research  Center  for 
Augmenting  Human  intellect,"  Proceedings  of  FJCC, 
33(1):395-410,  AFiPS  Press,  f^^ontvale,  NY,  1968. 

[Fair88]  FairCom,  c-tree™  File  Handler  Programmer's 
Reference  Guide,  FairCom,  Columbia,  MO,  May,  1988. 

[Gold89]  C.  Goldfarb,  A.  Talbot,  Journal  of  Development,  Part 
Two:  Standard  Music  Description  Language  (SMDL) 
Hypermedia/Time-based  Document  Subset  (HyTime). 
ANS!  X3V1.8M,  The  Computer  Music  Association,  P.O. 
Box  1634,  San  Francisco,  CA  94101-1634,  October 
31,  1989. 

[Ha!a89]  F.  Halasz,  M.  Schwartz,  "The  Dexter  Hypertext 
Reference  Model",  to  be  presented  at  the  N!ST 
Hypertext  Standardization  Workshop  on  January  16, 
1989. 

[Meyr86]  N.  Meyrowitz,  "Intermedia:  The  Architecture  and 
Construction  of  an  Object-Oriented  Hypermedia 
System  and  Applications  Framework,"  OOPSLA  '86 
Proceedings,  21(11):186-213,  ACM  SIGPLAN 
Notices,  November,  1986. 

[Nels81j  T.  Nelson,  Literary  l\/lachines:  The  Report  on,  and  of, 
Project  Xanadu,  Concerning  Word  Processing, 
Electronic  Publishing,  Hypertext,  Thinkertoys, 
Tomorrow's  Intellectual  Revolution,  and  Certain  other 
Topics  Including  Knowledge,  Education,  and  Freedom, 
Sv;arthmore,  PA,  1981.  Available  from  author. 

[Yank88a]  Yankelovich,  N.,  Haan,  B.,  Meyrov^'itz,  N.  and  Drucker, 
S.,  Intermedia:  The  Concept  and  Construction  of  a 
Seamless  Information  Environment,  iEEE  Computer, 
21(1):81-96,  1988. 


Strawman  Reference  Model  for  Hypermedia  Systems 

Craig  W.  Thompson 


Information  Technologies  Laboratory 
Texas  Instruments  Incorporated 
P.O  Box  655474,  MS  238 
Dallas,  Texas  75265 
Email:  thompson@csc.ti.com  Telephone:  (214)  995-0347 

Abstract 

This  paper  provides  a  strawman  reference  model  that  can  be  used  for  comparing  and  rea- 
soning about  hypertext/hypermedia  systems.  It  begins  with  a  glossary  of  hypermedia  terms. 
Agreeing  on  these  provides  a  common  vocabulary  for  developing  the  reference  model.  The  ref- 
erence model  itself  is  presented  in  terms  of  basic  features  all  hypermedia  systems  have,  advanced 
features  some  hypermedia  systems  have,  and  open  features  that  hypermedia  systems  share  with 
other  computer  systems.  These  features  represent  independent  dimensions  which  can  be  used 
to  classify  or  compare  existing  hypermedia  systems  and  to  contrast  thern  with  near-miss  related 
systems.  Based  on  the  features,  the  architecture  of  an  ideal  hypermedia  system  is  described 
that  covers  existing  hypermedia  systems.  The  architecture  is  modular.  A  consequence  is  that 
discussion  of  standards  or  a  more  detailed  reference  model  can  focus  on  one  module  at  a  time, 
avoiding  movement  toward  a  portmanteau  standard.  The  final  section  of  the  paper  evaluates 
some  areas  where  consensus  and  eventual  standardization  of  hypermedia  systems  is  possible 
and  would  be  valuable.  An  appendix  references  some  standards  related  to  hypermedia  sys- 
tems. Another  appendix  is  an  initial  document  log  listing  references  important  to  hypermedia 
standardization. 


-223- 


]  INTRODUCTION 


1  Introduction 

The  premise  of  the  Hypertext  Standardization  Workshop  is  that  "hypertext  and  hypermedia  tech- 
nologies have  reached  the  point  where  it  makes  sense  to  consider  their  potential  for  formal  stan- 
dardization" [Workshop  Call  for  Papers]. 

This  paper  provides  a  strawman  reference  model  that  can  be  used  for  comparing  and  reasoning 
about  hypertext/hypermedia  systems  and  suggests  some  areas  where  enough  consensus  could  occur 
to  make  eventual  standardization  possible. 

Section  2  provides  an  (incomplete)  glossary  of  hypermedia  terms.  A  standard  glossary  would 
provide  a  common  vocabulary  for  implementors  and  users  of  hypermedia  systems.  This  level  of 
standard  promotes  communication  among  people. 

Section  3  presents  a  strawman  hypermedia  reference  model.  Standardizing  on  a  reference  model 
should  make  it  possible  for  people  to  compare  different  hypermedia  systems  and  other  closely  related 
systems.  The  section  demonstrates  this  by  using  the  dimensions  of  a  hypermedia  system  described 
in  the  reference  model  to  compare  several  hypermedia  systems.  The  section  concludes  with  an 
ide?J,  modular  architecture  for  a  hypermedia  system. 

Operational  standards  should  make  it  possible  for  computer  systems  to  share  data  or  interface  to 
each  other.  Section  4  evaluates  potential  areas,  indexed  to  the  reference  model,  where  operational 
standards  for  hypermedia  systems  may  be  possible  and  would  be  valuable. 

Appendix  A  references  some  existmg  standards  related  to  hypermedia  systems.  Appendix  B  is 
a  place  holder  for  the  document  log  that  a  hypermedia  systems  study  group  would  maintciin. 

In  fact,  overall,  this  paper  can  be  viewed  as  the  skeleton  for  a  Final  Report  of  a  study  group 
yet  to  be  formed  recommending  whether  and  what  hypermedia  standardization  is  useful.  Such  a 
report  might  lead  to  the  formation  of  an  official  standards  body  charged  with  formulating  detailed 
hypermedia  standards. 

2  Glossary 

The  purpose  of  the  glossary  is  to  register  terms  and  how  they  are  used  in  different  hypertext 
systems.  The  value  of  a  glossary  in  standardization  is  to  provide  a  common  vocabulary  so  we  all 


-224- 


2  GLOSSARY 


understand  common  terms  the  same  way  and  can  distinguish  their  various  overloaded  meanings. 
In  addition,  glossary  terms  are  important  in  the  development  of  a  reference  model  (section  3)  and 
provide  a  simple  approximate  way  to  scope  a  domain.  Here  we  only  list  some  of  the  more  prominent 
terms  that  need  to  be  defined. 

hypertext 
hypermedia 
browser 
editor 

hypermedia  abstract  machine 

unique  id 

node 

cut-and-paste 
link 

warm  link 
hot  link 
field 
button 
anchor 

link  service 

link  protocol 

content 

annotation 

version 

conf  iguration 

web 

network 

guideline 

stack 


-225- 


3    REFERENCE  MODEL 


card 

background  card 

field 

locktext 

script 

scroll 

bookmark 

history 

map 

open  architecure 

Here  we  only  comment  that  some  terms  like  link  are  heavily  overloaded.  Other  terms  like  node, 
card,  frame  are  system-specific  names  for  the  approximately  the  same  concept. 

3    Reference  Model 

A  hypermedia  reference  model  is  an  English  description  of  characteristics  that  "cover"  existing  (and 
future)  hypermedia  systems  and  provide  people  with  a  way  to  compare  them. 

Subsections  3.1,  3.2,  and  3.3  sketch  basic,  advanced,  and  open  features  of  a  prototypical  hy- 
permedia system.  Each  feature  represents  an  independent  dimension  in  which  hypermedia  systems 
vary.  Subsection  3.4  compares  how  some  existing  hypermedia  systems  fit  this  model  and  how  some 
near-miss  systems  compare.  Subsections  3.5  and  3.6  describe  an  "ideal"  architecture  for  a  hyper- 
media system  based  on  the  premise  that  orthogonality  implies  modularity.  If  this  premise  is  correct, 
we  should  expect  to  concentrate  standardization  efforts  on  modules,  not  on  whole  systems. 

3.1     Basic  Features 

All  hypermedia  systems  have  the  following  basic  characteristics  or  dimensions  through  which  they 
vary  and  can  be  compared. 


-226- 


3    REFERENCE  MODEL 


The  representation  dimension  provides  the  primitive  media  types  or  content  part,  and  the  cona- 
positional  data  model  or  structural  part,  that  together  are  used  to  represent  information  in  a 
hypermedia  system.  It  is  convenient  to  distinguish  these  two  sorts  of  representations  as  separate 
dimensions. 

Media  Types.  A  hypertext  system  must  be  able  to  represent  text  (as  well  as  structure).  A 
hypermedia  system  adds  other  media  types  (bitmaps,  graphics,  sound,  video).  Specialized  media 
editors  are  needed  to  permit  WYSIWYG  editing  of  media  types.  Compression  of  media  types 
may  be  supported;  automatic  conversion  between  some  media  types  is  supported  (e.g.  graphic- 
to-bitmap).  (Various)  standards  already  exist  for  representing  many  of  these  media  types  (see 
Appendix  A). 

Data  Model.  A  data  mocie/ provides  the  structuring  primitives^  of  the  hypermedia  system.  To- 
gether, the  data  model  and  media  data  types  are  used  to  represent  ox  encode  the  application-specific 
information  content  in  a  hypermedia  information  system.  Specialized  hypermedia  interpreters,  usu- 
ally with  built-in  operations,  operate  on  the  basic  data  structures  of  the  data  model. 

Data  modeling  is  the  most  interesting  and  diverse  dimension  of  hypermedia  systems.  The  com- 
mon invariant  that  all  hypermedia  systems  share  is  the  notion  of  navigating  through  an  information 
space  by  following  links.  Beyond  that,  systems  vary  widely,  most  implementing  some  sort  of  se- 
mantic net  with  more  or  less  structure.  Many  hypermedia  glossary  terms  describe  system-specific 
data  model  concepts  (e.g.,  stack,  card,  history).  Nodes  may  be  inherently  unstructured;  they  may 
have  built-in  or  user  programmable  types;  or  they  may  have  attributes,  fields,  or  buttons.  Links 
also  vary.  Most  are  binary;  they  may  be  typed  and  have  attributes;  they  may  anchor  at  nodes  or 
within  nodes  in  a  media-  or  type-specific  or  application-specific  way;  or  they  may  be  built  from 
lower  level  primitives  {anchors  and  go  to's  as  in  HyperCard). 

While  data  models  differ  across  different  hypermedia  systems,  they  are  nearly  always  built-in  to 
today's  systems.  Later,  in  section  4  we  wiU  consider  when  and  whether  mappings  between  different 
data  models  are  possible. 

User  Interface.  The  user  interface  provides  the  capability  of  viewing  and  editing  (WYSI- 
WYG) presentations  of  information  represented  by  the  data  model  and  media  types. 

Hhe  hyper  in  hypermedia 


-227- 


3    REFERENCE  MODEL 


Some  hypermedia  systems  like  KfvIS  and  HyperCard  use  the  metaphor  of  a  "notecard"  and  only 
provide  fixed  (screen-sized)  cards  with  only  one  card  visible  at  a  time.  Others  like  NoteCards  use  an 
overlapping  or  tiled  window  system  metaphor  of  flexible-sized  cards  with  the  content  and  structure 
of  a  card  still  tied  one-to-one  to  the  display  window.  Guide  provides  scrolling  and  progressive 
disclosure,  a  step  towards  providing  the  user  with  control  of  which  objects  he  can  see  on  a  screen. 
More  generally,  a  many-many  view  mapping  like  that  in  CMU  Andrew  covers  all  of  the  above  cases. 

Persistence.  Hypermedia  systems  all  provide  some  notion  of  transferring  application-specific 
content  and  structure  to  and  from  some  persistent  storage  repository.  They  vary  on  the  unit  of 
transfer  (e.g.  Guide  document,  HyperCard  card,  Notecards  application)  and  the  file  or  database 
format  they  use  to  encode  the  data  represented  by  the  data  model. 

3.2     Advanced  Features. 

Not  all  hypermedia  systems  have  the  following  advanced  characteristics.  While  not  mandatory 
(essential,  intrinsic,  defining),  they  complement  the  basic  features  and  are  needed  for  non-trivial 
hypermedia  systems. 

Multi-usei".  Computer-supported  cooperative  work  requires  many  users  to  access  shared  data. 
Some  hypermedia  systems  support  this.  Sharing  by  multiple  users  adds  the  need  for  some  concur- 
rency control  scheme  like  locking  or  time-stamping  so  users  can  coordinate  access  to  shared  data. 
Data  and/or  structure  may  be  read-only  or  modifiable  according  the  access  rights  of  users.  Users 
can  be  granted  different  access  rights  at  different  times  or  for  different  purposes. 

Distributed.  Even  for  a  single  user,  hypermedia  data  may  be  stored  in  a  central  repository  or 
be  distributed.  For  instance,  content  may  be  on  a  WORM  device  and  structure  may  be  stored  in 
a  relational  database. 

Uniform  Representation^  Many  hypermedia  systems  make  a  distinction  betw^een  node  and 
contents.  This  forces  the  user  to  "chunk"  the  information  he  wants  to  represent  into  some  fixed 
grain-size.  This  can  lead  to  users  spending  time  manually  restructuring  information.  Advanced 
systems  provide  a  more  recursive  formulation  of  the  data  model  allowing  content  to  contain  nodes 

'This  feature  is  not  independent  of  the  data  modeling  feature  presented  earlier  but  is  included  here  as  a  major 
dimension  for  comparing  advanced  hypermedia  systems. 


-228- 


3    REFERENCE  MODEL 


(further  structured  information).  This  extra  information  plus  a  richer  mapping  of  the  more  uniform 
data  model  to  the  user  interface  can  give  the  user  many  views  of  the  same  information.  Systems 
like  Guide  begin  to  take  advantage  of  this  by  allowing  the  user  to  control  which  objects  are  visible 
using  progressive  disclosure.  Intermedia  webs  allow  two  or  more  views  to  "share"  common  nodes. 
Systems  like  Lotus  Agenda  allow  the  user  to  reorganize  the  information  based  on  a  simple  form  of 
computed  view.  The  semantics  of  sharing  common  objects  from  different  perspectives  can  lead  to 
dangling  pointers  and  view  update  problems. 

A  different  aspect  of  uniform  representation  involves  the  ability  to  deal  with  foreign  nodes. 
These  are  nodes  whose  contents  are  opaque  to  the  hypermedia  system.  For  at  least  two  reasons, 
uniform  representations  must  generalize  to  account  for  these  foreign  representations.  First,  not  aU 
workstations  can  display  all  information,  so  video  or  even  graphic  information  will  remain  opaque 
on  these  workstations.  Second,  hypereditors  like  KMS  or  Neptune  can  bind  to  non-hypereditors, 
like  word  processors,  that  do  not  understand  link  protocols  (are  not  themselves  uniform;  do  not 
represent  their  internal  information  in  a  way  the  hypermedia  system  can  interpret).  In  this  case, 
links  typically  anchor  to  whole  nodes,  which  act  to  "wrap"  the  foreign  editor,  or  else  link  anchors 
consist  of  two  parts,  a  node  id  and  a  specifier,  often  written  in  a  script  language  that  can  be 
interpreted  by  a  foreign  tool,  telling  how  to  offset  into  the  foreign  representation.  Sun  provides  an 
application-independent  Link  Service  protocol  for  standardizing  cross-application  linking  as  does 
HP  New  Wave. 

One  last  variation  in  representation  is  whether  hypermedia  systems  permit  users  to  define  the 
scope  of  objects  like  figure,  section,  document,  library,  video  clip,  or  whether  these  types  are  built- 
in. 

Computational  Completeness.  The  computational  completeness  dimension  describes  how 
procedural  information  can  be  associated  with  the  hypermedia  data  model  to  model  behavioral 
aspects  of  the  information. 

Procedures  can  be  coupled  with  data  in  many  ways.  Most  characteristically,  an  anchor  contains 
a  script  (procedure  in  a  language  specialized  to  the  data  model  as  in  HyperCard)  that  is  triggered  if 
the  anchor  is  activated.  Alternatives  are  demons  and  rules  as  in  Object  Lens,  procedures  in  general 
purpose  languages  as  in  NoteCards,  assertions,  and  so  on.  Since  procedural  attachments  are  added 


-229- 


3    REFERENCE  MODEL 


dynamically,  there  must  be  an  interpreter  or  dynamic  compiler. 

This  dimension  is  the  hardest  to  transport  across  systems,  as  we  discuss  in  section  4. 

Query.  Hypermedia  information  spaces  are  often  large.  Navigation  is  used  for  browsing; 
bookmarks  for  going  to  known  places.  Search  is  used  for  locating  items  of  interest  by  their  charac- 
teristics. Some  dimensions  of  search  include  limiting  the  scope  or  order  of  a  search;  string  search 
versus  indexing  text;  boolean  search  predicates  and  their  possible  use  of  indices;  user-defined  search 
predicates;  incremental  search;  and  how  the  end  user  can  easily  specify  complex  searches. 

Another  dimension  involves  what  to  do  when  search  is  successful.  Alternatives  are  that  the 
search  results  in  a  computed  path  through  the  information  space  or  in  a  new  view  of  the  information 
space.  Much  work  from  the  database  and  information  retrieval  areas  is  useful  here.  Query  is  a  very 
rich  dim.ension. 

General-purpose  procedural  attachments  generahze  query  capabilities  and  many  hypermedia 
systems  contain  weak  or  no  specialized  query  facihties.  This  leaves  the  burden  of  specifying  complex 
queries  to  the  user  via  programming. 

Versions,  Configurations.  Especially  for  design  applications  (e.g.,  documents,  software), 
where  the  life  cycle  of  a  design  needs  to  be  represented,  a  Change  Tl/anajfemenf  data  model  consisting 
of  versions,  configuratioiis  a,nd  transformations  Is  useful  for  recording  change,  how  a  complex  object 
is  composed  of  its  parts,  and  how  change  propagates. 

Portmanteau  Features.  Subsection  3.4.2  describes  near-miss  systems  closely  related  to  hy- 
permedia systems.  We  can  mine  these  systems  for  other  characteristics  that  hypermedia  systems 
could  have.''  This  could  overload  hypermedia  systems  with  more  than  their  ordinary  meaning  but 
the  exercise  is  needed  to  determine  how  these  systems  differ  from  hypermedia  systems. 

3.3    Open  Features 

Open  features  are  generic  and  belong  to  many  or  all  computer  systems.  They  may  apply  in  special 

''For  example,  few  if  any  hypermedia  systems  provide  parsers  to  automatically  recognize  structure  in  unstructured 
information.  This  is  clearly  important  since  a  whole  hypermedia  business  could  be  built  around  structuring  the  mass 
of  unstructured  information.  Most  parser  technology  is  aimed  ?i  recognizing  already  designed  languages.  The  Oxford 
English  Dictionary  project  at  University  of  Waterloo  is  one  place  to  look  for  good  ideas  on  the  interplay  between 
parsing,  querying,  and  computed  data  models  induced  by  a  grammar. 


-230- 


3    REFERENCE  MODEL 


ways  to  hypermedia  systems. 

Hmnan  Factors.  This  dimension  measures  how  likeable,  usable,  and  effective  a  system  is  for 
the  tasks  it  is  designed  or  needed  for. 

Open  versus  Closed  Architectures.  Hypermedia  systems  vary  along  the  dimension  of  hov/ 
closed  or  open  they  are;  that  is,  how  extensible  they  are.  Some  aspects  of  openness  are: 

•  none  browsers 

•  editing  only  -  simple  authoring  systems  like  Guide 

t  user  can  add  node  and  link  types;  or  can  specialize  classes  the  system  defines. 

•  user  can  provide  procedural  attachments 

•  system  has  an  application  program,  interface 

•  system  is  modular  and  modules  can  be  replaced 

Monolithic  versus  Modular  Architecture  Today's  hypermedia  systems  are  monolithic.  An 
alternative  is  a  modular,  toolkit  architecture  in  which  modules  can  be  added  or  replaced  as  the  need 
arises.  This  would  mean  that  design  applications  could  make  use  of  the  change  management  module 
but  other  applications  would  not  have  to  pay  this  cost.  If  some  specialized  change  management 
is  needed,  only  that  module  is  replaced.  The  modules  themselves  may  be  open--e.g.,  the  query 
optimizer  could  be  programmable;  the  version  scheme's  notion  of  deltas  could  be  too;  pragmas 
might  control  how  objects  are  clustering  on  disk;  new  kinds  of  presentations  could  be  added  to  the 
user  interface.  A  key  issue  related  to  modularity  involves  determining  the  protocols  an  existing 
foreign  editor  must  implement  to  become  a  friendly  hypereditor.  It  is  more  likely  that  "the  world's 
best  editors"  can  be  modified  to  be  hypermedia-conformant  than  that  hypermedia  editors  will  come 
to  rival  these  editors. 

Portability  and  Industrial  Strength.  The  portability  dimension  describes  how  a  system  is 
bound  to  its  environm.ent  and  how  easily  it  can  be  moved  to  other  environments.  It  will  be  more 
portable  if  1)  it  is  implemented  on  de  facto  standard,  industrial  strength  platorms  (Unix,  DCS. 
X-Windows,  C  +  +  ,  SQL,  etc),  2)  it  contains  alternative,  equivalent  implementations  for  different 


-231- 


3    REFERENCE  MODEL 

environments  (Open  Look  versus  Presentation  Manager),  and  3)  it  can  exchange  data  with  many 
existing,  popular  data  exchange  formats. 

A  hypermedia  system  is  industrial  strength  if  1)  it  is  debugged  and  maintained,  2)  it  scales 
up  for  large  hypermedia  bases,  3)  performance  is  acceptable,  4)  it  has  (online)  documentation  and 
tutorials,  5)  it  is  portable,  and/or  6)  it  is  being  used  in  practice. 

Cost,  Availability,  Service.  The  world's  best  designed  hypermedia  system  is  worth  less  if  it 
is  too  costly,  unavailable,  breaks,  and  so  on.  This  dimension  is  a  non-technical  road  block  to  many 
systems. 

Packaging.  This  characteristic  represents  the  particular  binding  of  all  previous  characteristics 
that  defines  any  given  system.  It  is  measured  by  some  sort  of  success  metric. 

3.4    Comparison  of  Existing  Systems 

If  the  reference  model  just  defined  is  successful,  we  should  be  able  to  compare  existing  and  related 
systems  using  the  dimensions  it  defines. 

3.4.1     Comparison  with  Other  Hypermedia  Systems 
Figure  1  makes  this  comparison  for  existing  hypermedia  systems. 


HyperCard 

Notecards 

Guide/IDEX 

Intermedia 

KMS 

media  types 

bitmaps  text 
sound 

text  bitmaps 
other 

text 

import  bitmaps 

all 

text 
graphics 

d&tA  model 

stack 
f/bkgnd  card 
field  button 
go  to 

card 
fllebos 
link 
other 

guideline 
buUon  note 
replacement 
inquiry 

web 
node 
link 

network 

frame 
6eld  link 

user  interface 

card  =  jcreen 
11 
jcroll  text 

card  =  wlndow 
1  I 

scroll  node 

IN 
scroll 

card  =  window 

1:1 

scroll  node 

card  =  screen 
11 

no  scrolling 

persistence 
unit  of  tranifcr 

card 

application' 

guideline/node 

node 

frame 

muUi-  user 

no 

ne  ' 

no/yes 

yes 

ye* 

distributed 

no 

no 

no / yef 

yes 

yes 

uniform 
representation 

no 

no 

limited 

no 

no 

programmable 

script  XCMD 

lisp 

no/guidance 

no 

action 

query 

no 

no 

no 

no 

no 

change  management 

no 

no 

no 

no 

no 

open  data  model 

mirror 

any 

no 

no 

mirror 

monolithic  vs 
modular 

monolit  hie 

monolithic 

monolithic 

monolit  hie 

monolit  hie 

Table  1:  Comparison  of  Hypermedia  Systems  by  Basic/ Advanced  Feature 


-232- 


3    REFERENCE  MODEL 


3.4.2     Relationsliip  of  Hypermedia  Systems  to  Near-Miss  Systems 

A  hypermedia  reference  model  must  also  allow  comparison  with  similar  systems  that  are  not  usually 
classified  as  hypermedia  systems.  The  big  question  is,  if  we  factor  these  systems  into  their 
characteristic  dimensions,  then  how  much  overlap  would  there  be  between  systems.^ 

Prograrmning  language  data  structures  mclndlng  object-oriented  programming^  and  A I  knowledge 
representations  including  frame-based  systems^  carry  data  modeling  much  further  than  hypermedia 
systems  do  today.  They  provide  better  uniform  representations  but  have  no  particular  support 
for  foreign  objects.  In  particular,  object-oriented  programming  languages  like  C  +  +  ,  CLOS,  and 
Smalltalk  have  common  characteristics  including  object  identity,  encapsulation,  types  or  classes, 
and  (multiple)  inheritance;  and  they  provide  procedural  attachment.  These  systems  make  a  strong 
type-instance  distinction  and  some  only  allow  creation  of  new  data  types  at  compile  time. 

Persistent  programming  languages  make  the  data  model  of  the  programming  language  incremen- 
tally persistent,  managing  secondary  storage,  concurrency,  and  recovery.  Object-oriented  databases 
add  sets,  queries,  and  indexing;  and  also  change  management  and  schema  evolution  to  persistent 
languages,  but  take  no  particular  stand  on  user  interfaces.  As  such,  they  generalize  relational 
database  systems,  though  implementations  of  the  latter  are  far  more  mature.  Even  more  special- 
ized are  implementations  of  information  retrieval  systems  which  store  large  text  bases  persistently, 
support  indexing,  but  typically  provide  no  editing,  data  modeling,  and  only  specialized  query  lan- 
guages. Geographic  information  systems  store  graphical  information  in  often-specialized  databases. 

User  interface  management  systems  allow  simple  user  interfaces  to  be  built  quickly.  User  inter- 
face toolkits  like  Stanford  Interviews  and  CMU  Andrew  provide  general  purpose  interface  building 
kits  but  require  programming  to  put  the  pieces  together.  They  do  not  commit  to  any  particular  data 
model.  In  general,  object  libraries  are  a  way  to  package  up  collections  of  related  objects  for  reuse  in 
building  large  systems.  Structured  graphics  editors  can  make  use  of  such  systems  to  build  generic 
shapes.  Programming  language  inspectors  and  class  browsers  can  be  viewed  as  specialized  hyper- 
media systems  for  viewing  rich  representations.  DIKED  editors,  e-mail  previewers,  CAD  schematic 
editors,  CASE  interfaces,  and  other  semantically  specialized  graphics  editors  can  browse  and  edit 

*A  related  implementation  question  is,  are  we  building  almost  the  same  systems  over  and  over  without  factormg 
out  the  common  modules' 


-233- 


3    REFERENCE  MODEL 


many  views  of  domain-specific  structured  data  types.  Personal  Information  5i/5i!e77i5  like  Symantec 
GrandView  and  Lotus  Agenda  provide  many  views,  including  hierarchical  views,  of  simple  records 
via  cross  indexing. 

The  kind  of  objects  represented  by  these  systems  are  usually  but  not  necessarily  fine-grained. 
Computer-aided  publishing  (CAP)  systems  add  primitive  objects  like  text  rectangles  that  may  be 
large  and  may  contain  embedded  objects.  Text  and  document  markup  languages  represent  the 
content  of  very  rich  hypertext-like  systems  often  specialized  to  document  preparation  but  also  used 
as  the  external  representations  of  WYSIWYG  document  preparation  systems  like  Framemaker. 
Syntax-directed  structure  editors  parse  structured  text  and  permit  editing,  pretty  printing,  and 
controlled  viewing  of  programs. 

Finally,  where  Office  Document  Architecture  only  distinguishes  a  structural  and  a  page  layout 
architecture  for  text,  graphics,  and  other  static  media,  technologies  like  Digital  Video  Interactive 
specify  how  to  temporally  sequence  video  and  sound  and  introduce  compression. 

All  of  these  systems  are  almost  hypermedia  systems.  Some  introduce  new  features  including 
richer  data  modehng  and  compression;  others  seem  more  like  elements  of  a  hypermedia  toolkit  since 
they  overlap  hypermedia  systems  concentrating  only  on  one  basic  or  advanced  feature  or  another. 

3.5     Architecture  of  an  Ideal  Hy  permedia  System 

Figure  1  represents  an  ideal  hypermedia  system  that  covers  all  of  the  basic  and  advanced  features 
described  earlier  in  this  section.  The  key  point  of  the  architecture  is  that  it  is  modular  and 
open.  This  modularity  is  based  on  the  observations  that  the  functions  the  modules  perform  are 
independent  of  each  other,  that  is  orthogonality  implies  modularity.  The  only  required  modules  for 
a  basic  hypermedia  system  are  the  User  Interface  Toolkit,  Domain-specific  Data  Modeling,  Type 
and  Object  Manager,  and  Persistent  Storage  modules. 
Module  independence  is  justified  as  follows: 

•  Media  types  provide  primitive  representations  for  text,  bitmaps,  audio,  video,  graphics. 

•  The  data  model  represents  structure  (nodes,  relationships,  and  content)  uniformly.  It  defines 
what  the  hypermedia  system  can  represent.  Speciahzations  can  define  hypermedia  objects 
like  card  or  field  or  they  can  define  domain-specific  objects  like  transistor  or  module. 


-234- 


3    REFERENCE  MODEL 


Change  Management 

Control  versions,  configu- 
rations, and  translormatlons 
Schema  evolution 


Object  Query 

Associative,  optinriizable 
queries  over  collections 
of  objects 


Extended  Transactions 

AppDcatlon-spedflc  concur- 
rency control  (non  2-phase) 
^49ste^d  transactlorts 
■Cooperative  wort< 


tJser  Interface 
Too  Ik  H 

-Object-oriented  browsing 
•Progressive  disclosure 


.^.<';-Siv'/.%'-:-;-:-i':-^>^-ii^ 

Domain  Specific  Data  Modeling 

■Hyperrriedia,  CAD,  CASE,  etc. 

Type  Manager 

Object  Manager 

-Type  definltltons 

-Maintain  consistent 

-Media  types 

runtime  environment 

Programming 
Language 


Persistent  Object  Store 

-Object  storage  with 

object  identity 
-Use  of  Inter-object  refer- 

ervces  for  placement 


Object  Communlcallons 

-Reliable  delivery  of  objects 
-Remote  Procedure  Calls 


Object  Translation 

-internal  <->  external 
object  transaltion 


Transactional  Store 

Atomic,  recoverable  storage 
of  untyped  "bit-buckets" 
Rudimentary  concurrency  control 


^M^-^    Message  passing  BUS 


Figure  1:  Proposed  Ideal  Hypermedia  System  Architecture. 

•  Structure  and  content  can  be  displayed  in  many  ways  (or  not  at  all)  so  the  presentation 
layer  is  independent.  This  can  be  implemented  with  a  data  model-independent  user  interface 
toolkit. 

•  Whether  and  how  this  information  is  mapped  to  permanent  storage  is  again  independent  of 
what  is  represented,  so  the  storage  system  is  orthogonal.  Implement  this  with  an  persistent 
programming  language.^ 

•  Queries  and  indexing  are  related  only  to  whether  there  are  sets,  collections,  or  other  navigation 
paths  to  iterate  through  and  whether  there  is  cached  information  (indexes)  that  can  be  used  to 
limit  the  search.  Implement  this  with  the  open  query  module  of  an  object-oriented  database. 

•  Systems  may  or  may  not  version  their  structure  and  content.  How  they  do  this,  if  they  do,  can 


^View-independence  and  Storage-independence  from  representation  are  similar  to  the  famous  3-tier  model  of 
databases. 


-235- 


REFERENCE  MODEL 


be  studied  independently  of  what  they  represent,  how  it  is  viewed,  or  whether  it  is  persistent. 
Implement  this  with  a  separate  Change  Management  module. 

•  From  a  single  users  point  of  view,  whether  the  system  is  multi-user  or  not  is  largely  trans- 
parent; the  same  goes  for  whether  the  system  is  distributed. 

•  Implement  the  above  functions  modularly  with  weU-defined  interfaces  specified  between  mod- 
ules. 

3.6    Advantages  of  this  Architecture 

A  modular,  toolkit  architecture  like  the  one  described  in  the  previous  section  has  these  ad- 
vantages: 

-  The  architecture  could  be  used  to  build  existing  hypermedia  systems.  In  that  sense,  it 
covers  and  explains  these  systems. 

-  Related  systems  are  implementing  several  of  the  modules  needed  in  an  ideal  hypermedia 
system.  Work  on  class  Hbraries,  persistent  languages  and  OODBs,  and  user  interface 
toolkits  is  proceeding  in  parallel  with  work  on  hypermedia  systems. 

-  Since  the  architecture  is  modular,  modules  can  be  improved  individually  which  would 
incrementally  improve  the  system.  They  can  be  improved  by  different  research  groups  or 
vendors.  People  need  not  build  whole  hypermedia  systems  to  experiment  with  particular 
parts. 

-  It  will  be  easier  to  build  the  near-miss  systems  using  a  modular  hypermedia  toolkit  and 
the  extra  capabilities  they  add  to  the  toolkit  will  likely  benefit  existing  applications. 

-  Customized  system  that  only  use  the  modules  they  need  can  be  constructed. 

-  If  the  modules  are  orthogonal,  then  consensus  that  leads  to  standardization  should  con- 
centrate on  individual  abstractions,  not  portmanteau  standards  covering  many  essen- 
tially independent  parts. 

The  architecture  proposed  here  is  similar  to  the  proposed  architecture  for  Application  Inte- 
gration Frameworks  being  developed  by  several  industrial  consortia.  These  include:  USAF 


-236- 


REFERENCE  MODEL 


WRDC  Engineering  Infoimation  Systems  (EIS),  Object  Management  Group  (OMGj,  CAD 
Frameworks  Initiative  (CFI),  and  CASE  Integrated  Systems  (CIS).  As  shown  in  Figure  2,  all 
these  efforts  provide  an  object-oriented  software  backplane  architecture  into  which  software 
services  are  "plugged."  This  allows  new  applications  that  use  the  common  services  of  the 
framework  to  be  built  more  quickly  and  to  have  a  "uniform  semantics."  Applications  are 
simpler  to  implement  since  common  services  are  factored  out  and  provided  by  the  framework. 
To  date,  framework  services  include  common  link  protocols  like  Sun's  Link  Protocol,  help 
and  tutorial  services,  debugging  services,  and  change  management  services,  all  implemented 
on  top  of  file  systems. 


Generic 
Services 


Available  from 
Framework  vendors 


Today's  Application 

-Core  o(  application 
+ 

-User  Interface 
-Help 
-Tutorials 
-Data  modeling 
-Storage 


Application 


Modular  OODB  /  Hypermedia  S*rvlc«s 


S 

Q. 
1 


5 

9! 


r 

o 


8 
1 


E 
o 
•i 

11 


o 


c 


S 


t 

s 
I 


€5 


81 
S  8 

ii 


Message-Passing  "BUS"  ~  Software  BacKplana 


atlon 

0 

2 

1 

Q 

< 

s 

Services 


Tools  and 
Applications 


Figure  2:  Hypermedia  Modules  complement  Application  Integration  Frameworks. 


Missing  ingredients  from  these  framework  architectures  are  the  modules  offered  by  a  modular 
OODB,  which  would  permit  sharing  at  the  object  grain  size  instead  of  the  file  grain-size  and 
querying.  Also  missing  are  user  interface  toolkits  and  data  rrnodeling  facilities  needed  by  a 


-237- 


OPERATIONAL  STANDARDS:  WHERE  IS  CONSENSUS  POSSIBLE? 

hypermedia  system.  The  fram_ework  view  of  the  world  as  modular  services  fits  very  well  with 
the  proposed  modular  hypermedia  system  architecture. 

3.7  Conclusion 

The  reference  model  presented  in  this  section  is  incomplete.  More  work  is  needed  to  refine 
it  in  many  places.  Nevertheless,  we  have  shown  how  it  provides  a  way  to  compare  existing 
hypermedia  systems  along  orthogonal  dimensions  and  have  indicated  that  it  can  be  extended 
to  relate  hypermedia  systems  to  several  kinds  of  near-miss  systems.  Based  on  the  features 
of  hypermedia  systems,  an  ideal  architecture  for  a  hypermedia  system  was  presented  and 
advantages  of  this  architecture  were  described  and  related  to  the  architecture  of  Applica- 
tion Integration  Frameworks.  An  argument  was  given  for  how  a  modular  architecture  can 
accelerate  progress  towards  hypermedia  standardization. 

4     Operational  Standards:  Where  is  Consensus  Possible? 

Operational  standards  provide  means  for  different  computer  systems  to  agree  to  communicate 
or  interface  or  share.  Many  sorts  are  possible  in  the  hypermedia  area,  reflecting  the  indepen- 
dent dimensions  of  the  reference  model  presented  earlier.  This  section  identifies  some  areas 
where  hypermedia  standardization  might  succeed  and  be  useful. 

4.1     Common  Media  Type  Representations. 

Standards  already  exist  in  this  area.  Appendix  A  lists  some  of  these.  Different  media  have 
different  properties  (linea,r  or  2-D  in  time  or  space,  discrete  or  continuous,  etc).  Conversions 
among  some  media  representations  are  algorithmic  but  lose  information  (e.g.,  structured 
graphics  to  bitmap,  high  resolution  to  low  resolution).  Often,  higher-level  structured  (or 
other  media)  representations  are  represented  in  media  representations.  In  some  cases  we 
know  how  to  parse  the  media  ajgorithmicaily  to  recognize  this  information;  often  we  do  not. 


-238- 


OPERATIONAL  STANDARDS:  WHERE  IS  CONSENSUS  POSSIBLE? 


4.2  Common  Hypermedia  Abstract  Machine  and  Interchange  Format. 

The  data  modeling  module  of  a  hypermedia  system  (including  the  media  types)  can  be  rep- 
resented equivalently  as  1)  an  abstract  machine  which  includes  a  specification  of  operations 
on  data  (an  interpreter)  plus  an  internal  representation  of  the  data  it  can  operate  on  or  2) 
an  external  format  that  encodes  the  application-specific  content  of  the  system  for  storage  or 
transmission. 

The  Neptune  Hypermedia  Abstract  Machine  (HAM)  [7]  describes  a  semantic-net  abstract 
machine  that  includes  not  only  data  modehng  primitives  but  also  operations  for  managing 
change  and  querying.  Representation  primitives  are  nodes,  attributes,  and  values. 

By  itself,  a  semantic  net  data  model  is  so  weak  that  it  permits  any  structural  information 
to  be  encoded.  As  such,  it  represents  very  little  unless  an  interpreter  looks  at  the  data  (at 
attribute  names  Like  type).  An  ASCII  Unear  representation  of  a  semantic  net  would  have  the 
same  semantic-less  information-bearing  properties. 

A  semantic  net  representation  could  be  standardized  as  could  an  associated  linear  represen- 
tation format.  The  linear  format  could  use  Lisp-like  parentheses,  SGML-like  tags,  or  an  easy 
to  parse,  hard  to  understand  binary  format.  But  this  by  itself  says  nothing  about  whether 
hypermedia  systems  can  exchange  hypermedia  data  or  cooperate. 

4.3  Common  Data  Model. 

The  heart  of  a  hypermedia  system  is  the  information  it  can  represent.  Distinctions  like  text 
rectangle,  frame,  card,  field,  button,  breadcrumb,  and  so  on  provide  this  information.  Differ- 
ent hypermedia  systems  will  be  able  to  exchange  information  only  to  the  extent  that  there  are 
mappings  between  their  representation  primitives.  It  may  often  be  reasonable  to  map  a  font 
from  one  system  to  a  different  font  in  another  (but  not  always  for  all  purposes).  It  may  even 
be  reasonable  for  som.e  purposes  to  set  up  mappings  from  KMS  frames  to  Intermedia  nodes 
to  HyperCard  cards  to  Notecards.  Similarly,  Intermedia  links  can  be  mapped  to  HyperCard 
fields  with  simple  scripts  containing  "go  to"s.  If  N  hypermedia  systems  represent  the  same 
object  then  a  mapping  to  an  intermediate  form  does  not  lose  information  and  can  be  useful. 


-239- 


OPERATIONAL  STANDARDS:  WHERE  IS  CONSENSUS  POSSIBLE"^ 


We  often  need  to  perform  mappings  between  different  system's  representations:  if  conversion 
from  one  system  to  another  is  required,  we  try  to  map  as  much  information  as  is  useful. 
In  most  instances,  some  amount  of  conversion  can  happen  algorithmicaUy.  It  is  not  too 
interesting  that  specific  content  can  be  moved  between  hypermedia  systems  with  application- 
specific  mappings.  The  interesting  case  involves  whether  application-independent  conversion 
routine  between  two  systems  are  useful  or  possible. 

In  general,  mappings  can  be  one-way  (no  inverse);  they  can  be  non-unique;  and  they  can  lose 
information.  All  these  cases  happen  in  important  hypermedia  system.  Because  of  the  power 
of  scripts,  the  inverse  of  mapping  Intermedia  links  to  HyperCard  fields  and  go-to  scripts  is 
not  unique.  HyperCard  foreground  and  background  cards  can  be  mapped  to  KMS  frames 
but  the  "inheritance"  is  lost.  Guide's  variable-sized  text  nodes  would  need  to  be  mapped 
to  several  KMS  fixed-size  frames.  Structured  graphics  imported  into  Guide  is  converted  to 
bitmaps,  losing  the  structure.  And  so  on. 

Even  when  a  mapping  is  established,  data  exchange  between  different  hypermedia  systems 
will  often  not  preserve  the  look  antf /ee?  of  different  hypermedia  systems.  Thus  a  Guide  node 
may  map  to  a  HyperCard  text  field  but  the  progressive-disclosure-in-context  look  and  feel  of 
Guide  outline  processing  will  be  lost. 

With  all  these  caveats,  it  is  often  useful  to  build  generic  conversion  programs.  PC  and 
Macintish  application  commonly  convert  data  to  their  own  internal  formats,  often  losing  some 
information.  References  [13-15]  describe  systems  that  explore  the  problems  associated  with 
mapping  between  different  document  representations.  The  Berkeley  Vortex  system  explores 
how  to  maintain  an  incremental,  multiple  representation  mapping  between  a  WYSIWYG 
editor  and  a  markup  language  representation. 

While  it  is  fruitful  to  try  to  define  intermediate  forms  like  the  Dexter  Hypermedia  Interchange 
Format  [6]  that  permit  mapping  information  between  today's  intermediate  forms  (since  it 
points  out  exactly  where  the  mappings  cause  problems),  it  seems  unlikely  that  the  behavioral, 
script  component  so  dominant  in  HyperCard  can  be  captured  without  duplicating  the  entire 
HyperCard  script  interpreter  in  some  related  Hypermedia  system.  It  may  be  better  to  consider 


-240- 


OPERATIONAL  STANDARDS:  WHERE  IS  CONSENSUS  POSSIBLE? 


whether  richer,  more  uniform  representations  are  better  than  cards  and  slots. 

4.4  Common  Object  Libraries. 

The  X  Consortia  is  considering  a  standard  C-f--f  interface  to  X-Windows.  [13]  describes  a 
portable  Office  Document  Architecture  toolkit  consisting  of  C  subroutines  associated  with 
the  CMU  Andrew  Toolkit.  Stanford  Interviews  is  a  C  +  +  class  library  implementing  a  user 
interface  toolkit.  It  seems  likely  that  we  could  standardize  on  C++  hbraries  in  these  sorts 
of  area.  Such  libraries  could  implement  cards,  buttons,  and  so  on  but  could  also  uniformily 
implement  CAD  transisters  and  layout  structures. 

4.5  Standard  OODBs. 

X3/SPARC/DBSSG  has  recently  announced  the  OODB  Task  Group  which  is  chartered  to 
assess  the  potential  for  standardization  in  the  OODB  area.  This  is  especially  interesting  since 
many  hypermedia  researchers  look  forward  to  using  OODBs  to  help  implement  large,  shared 
hypermedia  systems.  This  effort  itself  may  involve  several  standards:  how  to  seamlessly 
interface  OODBs  to  various  languages  to  provide  persistence  and  sharing,  and  how  to  map 
data  between  languages  (hke  Sun's  XDR)  to  allow  cross-language  sharing. 

4.6  Abstract  Machines  for  Querying  and  Change  Management 

As  mentioned,  Neptune  HAM  defined  not  only  data  modeling  primitives  but  also  operations 
for  managing  change  and  querying.  These  are  independent  dimensions  and  should  be  treated 
as  separate  abstraction  machines.  The  query  engine  should  define  how  a  set-oriented  query 
engine  attaches  to  a  representation,  indexes  it,  and  permits  powerful  queries.  A  change  man- 
agement abstract  machine  defines  operations  on  versions,  configurations,  and  transformations. 


-241- 


CONCLUSIONS 
4.7     Link  Protocol 

Sun's  Link  Service  and  HP  New  Wave  both  define  a  protocol  applications  can  use  to  set  up 
various  kinds  of  cross-application  links.  HP  New  Wave  appears  more  powerful  in  that  it  would 
permit  cross-application  (key-board)  macros  based  on  the  link  service  and  implement  common 
system-wide  protocols  for  accessing  help,  tutorials,  and  other  common  services.  This  is  an  area 
of  potential  standardization  being  covered  by  the  several  Frameworks  consortia  mentioned  in 
section  3.6. 

A  Hypermedia  Standardization  Group  would  complement  the  Frameworks  effort  if  it  concen- 
trated on  making  some  of  the  services  described  above  available. 

5  Conclusions 

This  paper  has  provided  a  reference  model  for  comparing  hypermedia  systems  and  an  archi- 
tecture that  isolates  design  decisions  to  modules.  The  implication  is  that  we  can  consider 
separable  subsystems  in  isolation,  then  combine  the  parts  to  make  a  whole  hypermedia  sys- 
tem. 

Based  on  this  analysis,  several  areas  where  consensus  is  possible  were  isolated  including: 
media  representations,  data  model,  interchange  formats,  class  libraries  (for  media  types,  data 
modeling  types,  and  domain  specific  types  like  CAD),  user  interface  toolkit  class  libraries,  a 
standard  protocol  for  hnking,  standards  for  persistent  languages,  and  abstract  machines  for 
queries  and  change  management. 

Some  of  these  standards  exist,  some  are  being  pursued  by  other  official  or  de  facto  standards 
bodies,  and  some  are  new  possibilities.  While  it  seems  too  early  to  consider  standardizing 
today's  hypermedia  systems  with  their  several  limitations,  the  effort  toward  building  consen- 
sus is  helping  us  to  understand  these  systems  better  and  to  identify  potential  areas  where 
standards  can  help. 


-242- 


APPENDIX  A:  RELATED  STANDARDS  AND  COMMON  FORMATS 

6    Appendix  A:  Related  Standards  and  Common  Formats 

This  section  lists  some  common  external  representations  of  information  used  for  various  pur- 
poses. It  is  included  since  it  represents  a  beginning  of  a  section  on  related  stcmdards.  It  also 
demonstrated  some  of  the  breadth  of  kinds  of  objects  that  hypermedia  systems  will  need  to 
represent. 

communication  protocols 

SCSI  --  Small  Computer  Systems  Interface 
external  representations  for  data  structures 

XDR    --  Sun's  external  data  representation 
device- independent  procedural  page/screen  description  formats 

DVI     --  for  TEX 

ditroff  --  for  troff 

imPRESS(TM)  --  document  for  printing  on  an  IMAGEN  laser  printer 
EPS    --  Encapsulated  Postscript  --  generated  by  Adobe  Illustrator (TM) , 
Cricketdraw(TM) ,  Aldus  Freehand(TM)  on  the  Macintosh  and  Media 
Logic's  Artisan(TM)  on  the  Sun;  also  Display  Postscript  and 
color  versions 

media  type  interchange  formats  (specific  ''document  contents''  like 
characters,  raster  graphics,  geometric  graphics,  sound,  video, 
etc).     Note:  Several  of  these  representations  represent  structure 
and  content. 
ASCII  -  text 

DIF    --  Document  Interchange  Format  --  used  to  interchange  text  and 

formatting  instructions  across  a  wide  variety  of  wordprocessors 
and  publishing  systems 

troff  -  the  standard  Unix  text  processing  utility 

DCA     --  IBM's  Revisable  Form  Text  Document  Content  Architecture.  Many 
popular  word  processors  can  store  documents  in  this  format 


-243- 


APPENDIX  A:  RELATED  STANDARDS  AND  COMMON  FORMATS 


(including  IBM  Displaywriter(R) ,  WordPerfect (R) ,  Wang(R) , 
MultiMate(TM) ,  Wordstar2000 (R) ,  Samna  IV  (TM) ,  Of f iceWriter (R) , 
and  Microsoft  Word(R)  can  store  documents  in  this  format.  Does 
not  support  graphics. 

Scribe 

Tex,  LaTex  --  popular  text  formatting  language,  weak  on  non-textual 
objects,  primitives  for  tables 
,  MIF    --  Framemaker's  Maker  Interchange  Format 
Interleaf,  Microsoft  Word,  HyperCard,  WordStar,  Ventura,   ...  many 

products  provide  a  way  to  save  and  restore  their  state. 
EDA/VGA/CGA  --  bitmap  screen  sizes/resolutions  on  different  PCs 
X3H3  GKSM    --  Graphical  Kernal  System  Metafile  (polyline,  polymarker, 
text,  fill  area,  cell  array,  generalized  drawing  primitive) 
(A  second  metafile  standard  provides  a  way  to  encode  a  sq 
sequence  of  GKS  commands.    The  description  of  the  objects,  not 
the  image  is  saved. 

PHIGS 

GIF    --  graphic  interchange  format 
ISO  Computer  Graphics  Metafile 

PICT  --  Macintosh  standard  graphics  description  format 
pic    --  a  language  for  typesetting  graphics 

HPGL         a  popular  plotter  output  format  used  by  many  workstation  CAD 

programs  like  AutoCAD 
IGES    --  a  standard  graphics  interchange  format  used  by  many  workstation 

CAD  programs 

MacDraw  -  Macintosh(TM)  MacDraw  f iles--QuickDraw--toolbox  ROM  routines 
NTSC    --    U.S.  etc  television  format  standard  for  production  and 

transmission;  Europe  uses  PAL;  HDTV  and  ACTV  are  next 

generat  ion 


-244- 


APPENDIX  B:  DOCUMENT  LOG 

SMPTE    --  Society  of  Motion  Picture  and  Television  Engineers--time  code 
for  syncing  audio,  video,  film 
document/audio-video  representation  and  interchange  formats 

SGML  --  ANSI/ISO  Standard  Generalized  Markup  Language.    Uses  markups 

(tags)  to  create  an  indirections  between  intent  and  rendering. 
Does  not  support  graphics . 
ODIF  --  Office  Document  Interchange  Format.     ODA  distinguishes  a  logical 

hierarchy  and  a  layout  hierarchy 
CD-I  --  Compact  Disk  Interactive,  compression/decompression  formats 
DVI    --  Digital  Video  Interative.    Text,  audio,  video  stills,  and  video 
motion,  at  various  resolutions,  mixed, 
compression/decompression  formats 
cad-specific  interchange  formats 

EDIF  -~  Electronic  Data  Interchange  Format 
VHDL  --  VHSIC  Hardware  Description  Language 
CIF    --  Caltech  Interchange  Format 
product  interchange  format 

PDES  --  Product  Data  Exchange  Specification 
EDI    --  Electronic  Data  Interchange 

7    Appendix  B:  Document  Log 

The  document  log  lists  bibliographies,  conference  proceedings,  key  papers,  and  other  docu^ 
ments  that  are  related  to  the  hypermedia  standardization  effort. 

[1]  Jakob  Nielsen,  "Hypertext  Bibliography,"  Hypermedia,  Taylor  Graham  (ed),  1:1,  1989 
This  bibliography  references  key  papers  by  Bush,  Engelbart,  Kay,  and  Nelson;  surveys  anc 
books  by  Conklin  and  Schneiderman;  systems  like  Intermedia,  Neptune,  KMS,  HyperCard 
Notecards,  Guide,  Object  Lens;  and  other  technical  papers  on  hypermedia. 
[2]  Proceeding  of  the  ACM  SIGPLAN/SIGOA  Symposium  on  Text  Manipulation,  Portland 


-245- 


T    APPENDIX  B:  DOCUMENT  LOG 


Oregon,  June  8-10  1981.  Available  as  SIGPLAN  Notices  16(6)  or  SIGOA  Newsletter  2(1-2). 

[3]  Hypertext'87  Proceedings,  ACM  press,  Chapel  Hill,  NC,  November  13-15,  1987. 

[4]  Hypertext'89  Proceedings,  ACM  press,  Pittsburgh,  November  5-8,  1989. 

[5]  ACM  Conference  on  Document  Processing  Systems,  ACM  Press,  Santa  Fe,  New  Mexico, 
December  5-9,  1989. 

[6]  Bernstein,  Jeremy,  Frank  Halasz,  and  Tim  Oren.  "Dexter  Hypertext  Interchange  Format 
(DHIF)-Discussion  and  Format  Specification-version  1.4",  unpublished,  November  3,  1989. 

[7]  Campbell,  B.  and  J.  M.  Goodman.  "HAM:  A  General  Purpose  Hypertext  Abstract  Ma- 
chine," Comm.unications  of  the  ACM,  31:7,  July,  1988. 

[8]  IBM  (1983).  Document  Content  Architecture:  Revisable- Form-Text  Reference.  SC23- 
0758. 

[9]  International  Organization  for  Standardization  (1986).  Standard  Generalized  Markup 
Language.  ISO  DIS  8879. 

[10]  International  Organization  for  Standardization  (1986).  Computer  Graphics  Metaflie.  ISO 
IS  8632. 

[11]  International  Organization  for  Standardization  (1987).  Office  Document  Architecture. 
ISO  DIS  8613. 

[12]  Knoerdel,  J.  and  Ward  Watkins,  S.  (1984)  Document  Interchange  Format.  National 
Bureau  of  Standards,  NBSIR  84-2836. 

[13]  Sherman,  Mark.  "Experiences  Interchanging  Multimedia  Documents  using  ODA,"  Con- 
ference on  Nev/  Horizons  in  Electronic  Media,  International  Telecommunications  Union,  Oc- 
tober 4-7,  1989,  Geneva,  Switzerland,  pp  429-433. 

[14]  de  La  Beaujardiere,  Jean-Marie,  "Well- Established  Document  Interchange  Formats," 
Document  Manipulation  and  Typography,  J.C.  van  Vliet  (ed),  Cambridge  University  Press, 
1988. 

[15]  S  Mamrak,  M.  Kaelbling,  C.  Nicholas,  and  M.  Share.  "Chameleon:  A  System  for  Solving 
the  Data  Translation  Problem."  TR24,  Department  of  Computer  and  Information  Science, 
The  Ohio  State  University,  August,  1988. 

-246- 


APPENDICES 


-247- 


I 


I 


Hypermedia  Bibliography,  1989 


Paul  Kahn, 

Institute  for  Research  in  Information  and  Scholarship 
Brown  University,  Box  1946 
Providence  RI 02912 


Since  the  last  time  we  compiled  this  bibliography  in  November  1987  for  the  Hypertext  '87  Workshop, 
there  has  been  an  explosion  of  hypertext  literature.  When  we  started  the  bibliography  project  at  IRIS  in 
1983,  we  thought  it  would  be  possible  to  collect  every  book,  conference  paper  and  journal  article  on  the 
subject  of  hypertext.  In  1989,  that  seems  an  impossible  goal.  We  hope  our  collection  includes  a  large  portion 
of  the  current  literature,  but  every  day  we  learn  of  new  papers  that  are  not  part  of  our  collection. 

This  version,  prepared  for  distribution  by  NIST,  contains  orJy  references  to  material  we  have  been  able  to 
collect  over  the  past  six  years.  The  reference  list  differs  substantially  from  the  1987  version.  In  1987  there 
just  were  not  that  many  papers  focused  entirely  on  hypertext,  so  we  included  in  the  bibliography  many 
papers  that,  while  only  tangentially  related  to  the  topic  of  hypertext,  had  been  influential  in  helping  us 
think  about  the  subject.  Now  that  there  are  so  many  papers  focused  solely  on  hypertext,  we  have  opted  to 
narrow  the  scope  of  the  bibliography  and  include  only  those  references  that  are  exactly  on  the  topic. 

A  longer  version  of  this  bibliography,  containing  the  following  list  plus  an  annotated  list  of  selected  sources 
is  available  for  $3.00  from  IRIS  (Brown  University,  Box  1946,  Providence  RI  02912). 

This  bibliography  represents  a  collaborative  effort  of  not  only  members  of  the  IRIS  staff,  but  also  of  a  num- 
ber of  others  who  have  worked  on  compiling  bibliographies,  most  notably  John  Leggett  (Texas  A&M),  Jakob 
Nielson  (Technical  University  of  Denmark),  and  Rosemary  Simpson  (Boston  Computer  Society). 

The  list  of  references  below  is  arranged  alphabetically  by  first  author. 


Agosti,  Maristella.  "Is  Hypertext  A  New  Model  of 
Information  Retrieval?"  Proceedings  of  the  12th 
International  Online  Information  Meeting. 
December  6-8,  1988,  London,  England.  New  Jersey: 
Learned  Information,  1988.  57-62. 

Akscyn,  Robert  M.,  Donald  L.  McCracken  and  Elise 
A.  Yoder.  "KMS:  A  Distributed  Hypermedia 
System  for  Managing  Knowledge  in  Organizations." 
Communications  of  the  ACM,  Vol.  31,  No.  7  (July 
1988):  820-835. 

Akscyn,  Robert  M.  and  Donald  L.  McCracken.  "The 
ZOG  Approach  to  Database  Management."  Pro- 
ceedings of  the  Trends  and  Applications  Con- 
ference: Making  Databases  Work.  Gaithersburg, 
MD,  May,  1984. 

Alexander,  George.  "Knowledge  Management 
Systems  from  Scribe:  Hypertext  for  Groups."  The 
Seybold  Report  on  Publishing  Systems,  Vol.  18,  No. 
12  (1989):  11-17. 

Allen,  Todd,  Robert  Nix  and  Alan  Perlis.  "PEN:  A 
Hierarchical  Document  Editor."  Proceedings  of  the 
ACM  SIGPLAN/SIGOA  Conference  on  Text  Ma- 
nipulation. Portland,  Oregon,  June,  1981. 


Allinson,  Lesley  and  Nick  Hammond.  "A  Learning 
Support  Environment:  The  Hitch  Hikers  Guide."  in 
Hypertext:  Theory  into  Practice,  Ray  McAleese, 
(editor).  Norwood,  NJ:  Ablex  Publishing 
Corporation,  1989.  62-74. 

Alschuler,  Liora.  "Hand-Crafted  Hypertext- 
Lessons  from  the  ACM  Experiment."  in  The  Society 
of  Text:  Hypertext,  Hypermedia,  and  the  Social 
Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA:  The  MIT  Press,  1989.  343- 
361. 

Ambron,  Sueann  and  Kristina  Hooper.  Interactive 
Multimedia.  Redmond,  WA:  Microsoft  Press,  1988. 

Backer,  D.  and  Stephen  Gano.  "Dynamically 
Alterable  Videodisk  Displays."  Proceedings  of 
Graphics  Interface  82.  Toronto,  Canada,  May  1982. 

Baird,  Patricia  and  Mark  Percival.  "Glasgow  On- 
Line:  Database  Development  using  Apple's 
HyperCard."  in  Hypertext:  Theory  into  Practice, 
Ray  McAleese,  (editor).  Norwood,  NJ:  Ablex 
Publishing  Corporation,  1989.  75-92. 


Hypermedia  Bibliography 


-249- 


October  1989 


Barrett,  Edward.  The  Society  of  Text:  Hypertext, 
Hypermedia,  and  the  Social  Construction  of 
Information.  Cambridge,  MA:  The  MIT  Press,  1989. 

Baskir\,  A.  B.  "Logic  Nets:  Variable-Valued  Logic 
Plus  Semantic  Networks."  International  journal  on 
Policy  Analysis  and  Information  Systems,  Vol.  4 
(1980):  269. 

Beeman,  William  O.,  Kenneth  T.  Anderson,  Gail 
Bader,  James  Larkin,  Anne  P.  McClard,  Patrick  }. 
McQuillan  and  Mark  Shields.  "Hypertext  and 
Pluralism:  From  Lineal  to  Non-linea!  Thinking." 
Hypertext  '87  Papers.  November  13-15,  1987, 
Chapel  Hill,  NC.  New  York:  ACM,  1989.  67-88. 

Beeman,  William  O.,  Kenneth  T.  Anderson,  Gail 
Bader,  james  Larkin,  Anne  P.  McClard,  Patrick 
McQuillan  and  Mark  Shields.  Intermedia:  A  Case 
Study  of  Innovation  in  Higher  Education.  Final 
Report  to  the  AnnenbergjCPB  Project,  IRIS,  Brown 
University,  Providence,  RI,  1988. 

Begeman,  Michael  L.  and  Jeff  Conklin.  "The  Right 
Tool  for  the  Job."  Byte,  Vol.  12,  No.  10  (October 
-  1988):  255-266. 

Begeman,  Michael  L.,  P.  Cook,  Clarence  Ellis,  M. 
Graf,  G.  Rein  and  T.  Smith.  "PROJECT  NICK: 
Meetings  Augmentation  and  Analysis."  Computer- 
Supported  Cooperative  Work  (CSCW  '86)  Pro- 
ceedings. December  3-5,  Austin,  TX,  1986. 

Bernstein,  Mark.  "The  Bookmark  and  the  Compass: 
Orientation  Tools  for  Hypertext  Users,"  ACM 
SIGOIS  Bulletin.  Robert  B.  Allen,  (editor).  Vol.  9, 
No.  4  (October  1988):  34-45. 

Bender,  Walter.  "Imaging  and  Interactivity." 
Fifteenth  joint  Conference  on  Image  Technology. 
November,  Tokyo,  Japan,  1984. 

Bernstein,  Mark  (editor).  AI  and  Hypertext:  Issues 
and  Directions.  AAAI-88  Workshop  proceedings, 
August  1988,  St.  Paul,  MN,  Watertown,  MA: 
Eastgate  Systems,  Inc.,  1988. 

Bhargava,  Hemant,  Michael  Bieber  and  Steven  O. 
Kimbrough.  "OONA,  MAX  and  the  WYWWYWI 
Principle:  Generalized  Hypertext  and  Model 
Management  in  a  Symbolic  Programming 
Environment."  Proceedings  of  ICIS  '88.  179-191. 

Bieber,  Michael  and  Steven  O.  Kimbrough.  On 
Generalizing  the  Concept  of  Hypertext,  Technical 
Report  BCCS-89-03,  Computer  Science  Department, 
Boston  College,  Chestnut  Hill,  MA,  September 
1989. 


Bigelow,  James  and  Victor  Riley.  "Manipulating 
Source  Code  in  Dynamic  Design."  Hypertext  '87 
Papers.  November  13-15,  1987,  Chapel  Hill,  NC. 
New  York:  ACM,  1989.  397-408. 

Biggerstaff,  Ted,  Clarence  Ellis,  Frank  G.  Halasz, 
C.  Kellogg,  C.  Richter  and  D.  Webster.  "In- 
formation Management  Challenges  in  the  Software 
Design  Process."  Database  Engineering,  Vol.  10,  No. 
1  (March,  1987):  24-31. 

Binder,  Carl.  "The  Promise  of  a  Paperless 
Workplace."  Optical  Insights,  (Fall  1987). 

Binder,  Carl,  "The  Window  Book  Technology." 
Boston  Computer  Society  Training  and  Doc- 
umentation Newsletter,  (Fall  1986). 

Bjorklund,  Lisbeth,  Birgitta  Olander  and  Linda  C. 
Smith.  "The  Personal  Hypercatalog."  Annual 
Meeting  of  the  American  Society  for  Information 
Science.  October  30-November  1,  1989,  Washington, 
DC,  1989. 

Blair,  David  C.  and  M.  E.  Maron.  "An  Evaluation  of 
Retrieval  Effectiveness  for  a  Full-Text  Document- 
Retrieval  System."  Communications  of  the  ACM, 
Vol.  28,  No.  3  (March  1985):  289-299. 

Bolt,  Richard  A.  Spatial  Data-Management, 
DARPA  Report,  MIT  Architecture  Machine  Group, 
Cambridge,  MA,  1979. 

Bolter,  Jay  David  and  Michael  Joyce.  "Hypertext 
and  Creative  Writing."  Hypertext  '87  Papers. 
November  13-15,  1987,  Chapel  Hill,  NC.  New 
York:  ACM,  1989.  41-50. 

Bourne,  John  R.,  Jeff  Cantwell,  Authur  J.  Brodersen, 
Brian  Antao,  Antonis  Koussis  and  Yen-Chun  Huang. 
"Intelligent  Hypertutoring  in  Engineering." 
Academic  Computing,  (September  1989):  18-20,  42- 
48. 

Bovey,  J.  D.  and  Peter  J.  Brown.  "Interactive 
Document  Display  and  its  Use  in  Information 
Retrieval."  journal  of  Documentation,  Vol.  43,  No.  2 
(June  1987):  125-137. 

Brockmann,  R.  John,  William  Horton  and  Keven 
Brock.  "Limited  Freedom:  Linear  Reflections  on 
Nonlinear  Texts."  in  The  Society  of  Text:  Hy- 
pertext, Hypermedia,  and  the  Social  Construction 
of  Information,  Edward  Barrett,  (editor). 
Cambridge,  MA:  The  MIT  Press,  1989. 162-205. 


Hypermedia  Bibliography  NISI  Version 


-250- 


January  1990 


Brown,  John  Seely.  Notes  Concerning  Design 
Functionality,  Issues  and  Philosophy  for  an 
AuthoringLand,  Xerox  Palo  Alto  Research  Center, 
Palo  Alto,  CA,  February  1982. 

Brown,  John  Seely.  "Process  versus  Product:  A 
Perspective  on  Tools  for  Communal  and  Informal 
Electronic  Learning."  in  Education  in  the  Electronic 
Age:  A  Report  from  the  Learning  Lab, 
WNET/Thirteen  Learning  Lab.  New  York:  WNET, 
1983.  41-58. 

Brown,  Peter  J.  "Interactive  Documentation." 
Software-Practice  and  Experience,  Vol.  16,  No.  3 
(March  1986):  291-299. 

Brown,  Peter  J.  "A  Simple  Mechanism  for  the 
Authorship  of  Dynamic  Documents."  in  Text 
Processing  and  Document  Manipulation:  Proceedings 
of  the  International  Conference,  J.  C.  van  Vliet, 
(editor).  Cambridge:  Cambridge  University  Press, 
1986.  34-42. 

Brown,  Peter  J.  "Viewing  Documents  on  a  Screen."  in 
CD-ROM:  The  New  Papyrus,  Steve  Lambert  and 
Suzanne  Ropiequet,  (editors).  Redmond,  WA: 
Microsoft  Press,  1986. 175-186. 

Brown,  Peter  J.  "On-Line  Documentation."  in  State 
of  the  Art  in  Computer  Graphics,  Earnshaw, 
(editor).  Springer-Verlag,  1987. 

Brown,  Peter  J.  "Turning  Ideas  into  Products:  The 
Guide  System."  Hypertext  '87  Papers.  November 
13-15,  1987,  Chapel  Hill,  NC.  New  York:  ACM, 
1989.  33-40. 

Brown,  Peter  J.  "Hypertext:  The  Way  Forward."  in 
Document  Manipulation  and  Typography,  J.  C.  van 
Vliet,  (editor).  Cambridge:  Cambridge  University 
Press,  1988.  183-191. 

Brown,  Peter  J.  "Linking  and  Searching  in 
Hypertext."  EP-odd,  Vol.  1,  No.  1  (1988):  45-53. 

Buchert,  R.  F.,  K.  H.  Evers  and  P.  R.  Santucci. 
"SADT/Saint  Simulation  Technique."  National 
Aerospace  and  Electronics  Conference  Proceedings. 
1981, 

Bush,  Vannevar.  "As  We  May  Think."  Atlantic 
Monthly,  Vol.  176,  No.  1  (July  1945):  101-108. 

Bush,  Vannevar.  "Memex  Revisited."  in  Science  Is 
Not  Enough  by  Vannevar  Bush.  New  York: 
WilUam  Morrow,  1967.  75-101. 


Hypermedia  Bibliography  NIST  Version 


Campbell,  Brad  and  Joseph  M.  Goodman.  "HAM:  A 
General  Purpose  Hypertext  Abstract  Machine." 
Communications  of  the  ACM,  Vol.  31,  No.  7  (July 
1988):  856-861. 

Carlson,  Patricia  Ann.  "Hypertext  and  Intelligent 
Interfaces  for  Text  Retrieval."  in  The  Society  of 
Text:  Hypertext,  Hypermedia,  and  the  Social 
Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA:  The  MIT  Press,  1989.  59- 
76. 

Carmody,  Steve,  W.  Gross,  Theodor  H.  Nelson, 
David  E.  Rice  and  Andries  van  Dam.  "A  Hypertext 
Editing  System  for  the  /360."  in  Pertinent  Concepts 
in  Computer  Graphics,  M.  Faiman  and  J. 
Nievergelt,  (editors).  University  of  Illinois  Press, 
1969.  63-88. 

Carr,  C.  "Hypertext:  A  New  Training  Tool?" 
Educational  Technology,  Vol.  28,  No.  8  (1988):  7-11. 

Carroll,  John  M.  and  Amy  P.  Aaronson.  "Learning  by 
Doing  with  Simulated  Intelligent  Help."  in  The 
Society  of  Text:  Hypertext,  Hypermedia,  and  the 
Social  Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA:  The  MIT  Press,  1989.  423- 
452. 

Cashin,  P.,  M.  Robinson  and  D.  Yates.  "Experience 
with  SCRAPBOOK,  A  Non-Formatted  Data  Base 
System."  Proceedings  IFIPS  Congress,  1973. 

Catano,  James  V.  "Poetry  and  Computers: 
Experimenting  with  the  Communal  Text."  Com- 
puters and  the  Humanities,  Vol.  13  (1979):  269-275. 

Catlin,  Timothy,  Paulette  E.  Bush  and  Nicole 
Yankelovich.  "InterNote:  Extending  a  Hypermedia 
Framework  to  Support  Annotative  Collaboration." 
Hypertext  '89  Proceedings.  November  5-7,  1989, 
Pittsburgh,  PA.  New  York:  ACM,  1989.  365-378. 

Catlin,  Timothy  J.  O.  and  Karen  E.  Smith.  "Anchors 
for  Shifting  Tides:  Designing  a  'Seaworthy' 
Hypermedia  System."  Proceedings  of  the  12th 
International  Online  Information  Meeting. 
December  6-8,  1988,  London,  England.  Oxford  and 
New  Jersey:  Learned  Information,  1988. 15-25. 

Charney,  Davida.  "Comprehending  Non-Linear 
Text:  The  Role  of  Discourse  Cues  and  Reading 
Strategies."  Hypertext  '87  Papers.  November  13-15, 
1987,  Chapel  Hill,  NC.  New  York:  ACM,  1989.  109- 
120. 

Charney,  Davida  and  Lynne  M.  Reder.  "Designing 
Interactive  Tutorials  for  Computer  Users."  Human- 
Computer  Interaction,  Vol.  2,  No.  4  (1986):  297-317. 

-251-  January  1990 


Chignell,  Mark  H.  and  Richard  M.  Lacy.  "Project 
Jefferson:  Integrating  Research  and  Instruction." 
Academic  Computing,  (September  1988):  12-17,  40. 

Christodoulakis,  Stavros  and  Stephan  Graham. 
"Browsing  Within  Time-Driven  Multimedia 
Documents."  Conference  on  Office  Information 
Systems.  Robert  B.  Allen,  (editor).  March  23-25, 

1988,  Palo  Alto,  CA.  New  York:  ACM,  1988.  219- 
227. 

Claassen,  W.  T.  and  T.  J.  D.  Bothma.  "Structuring 
Diverse  Types  of  Information  in  Hypertext:  The 
Case  of  Biblical  Information."  Proceedings  of  the 
12th.  International  Online  Information  Meeting. 
December  6-8,  1988,  London,  England.  Oxford  and 
New  Jersey:  Learned  Information,  1988.  83-90. 

Clitherow,  Peter,  Doug  Riecken  and  Michael 
Muller.  "VISCAR:  A  System  for  Inference  and 
Navigation  of  Hypertext."  Hypertext  '89 
Proceedings.  November  5-7,  1989,  Pittsburgh,  PA. 
New  York:  ACM,  1989.  293-304. 

Collier,  George  H.  "Thoth-II:  Hypertext  with 
Explicit  Semantics."  Hypertext  '87  Papers.  Novem- 
ber 13-15,  1987,  Chapel  Hill,  NC.  New  York:  ACM, 

1989.  269-290. 

Combelic,  D.  "User  Experience  with  New  Software 
Methods  (SADT)."  Proceedings  of  the  National 
Computer  Conference,  1978.  631-633. 

Conklin,  Jeff.  A  Survey  of  Hypertext,  MCC 
Technical  Report  STP-356-86,  Rev.  2.  MCC 
Software  Technology  Program,  Austin,  TX, 
December  3, 1986. 

Conklin,  Jeff.  "Hypertext:  An  Introduction  and 
Survey."  IEEE  Computer,  Vol.  20,  No.  9  (September, 
1987):  17-41. 

Conklin,  Jeff  and  Michael  L.  Begeman.  "gIBIS:  A 
Hypertext  Tool  for  Team  Design  Deliberation." 
Hypertext  '87  Papers.  November  13-15,  1987, 
Chapel  Hill,  NC.  New  York:  ACM,  1989.  247-252. 

Conklin,  Jeff  and  Michael  Begeman.  "gIBIS:  A  Tool 
for  All  Reasons."  Journal  of  American  Society  for 
Information  Science,  Vol.  40,  No.  3  (May  1989):  200- 
213. 

Consens,  Mariano  P.  and  Alberto  O.  Mendelzon. 
"Expressing  Structural  Hypertext  Queries  in 
GraphLog."  Hypertext  '89  Proceedings.  November 
5-7,  1989,  Pittsburgh,  PA.  New  York:  ACM,  1989. 
269-292. 


Cooke,  Peter  and  Ian  Williams.  "Design  Issues  in 
Large  Hypertext  Systems  for  Technical  Doc- 
umentation." in  Hypertext:  Theory  into  Practice, 
Ray  McAleese,  (editor).  Norwood,  NJ:  Ablex 
Pubhshing  Corporation,  1989.  93-104. 

Corda,  U.  and  G.  Facchetti.  "Concept  Browser:  A 
System  for  Interactive  Creation  of  Dynamic 
Documentation."  in  Text  Processing  and  Document 
Manipulation:  Proceedings  of  the  International 
Conference,  J.  C.  van  Vliet,  (editor).  Cambridge: 
Cambridge  University  Press,  1986. 

Crane,  Gregory.  "From  the  Old  to  the  New: 
Integrating  Hypertexts  into  Traditional  Schol- 
arship." Hypertext  '87  Papers.  November  13-15, 
1987,  Chapel  Hill,  NC.  New  York:  ACM,  1989.  51- 
56. 

Croft,  W.  Bruce  and  Howard  Turtle.  "A  Retrieval 
Model  Incorporating  Hypertext  Links."  Hypertext 
'89  Proceedings.  November  5-7,  1989,  Pittsburgh, 
PA.  New  York:  ACM,  1989.  213-224. 

Crouch,  Donald  B.,  Carolyn  J.  Crouch  and  Glenn 
Andreas.  "The  Use  of  Cluster  Hierarchies  in 
Hypertext  Information  Retrieval."  Hypertext  '89 
Proceedings.  November  5-7,  1989,  Pittsburgh,  PA. 
New  York:  ACM,  1989.  225-238. 

Dede,  Christopher  J.  "Empowering  Environments, 
Hypermedia,  and  Micro  worlds."  The  Computing 
Teacher,  Vol.  15,  No.  3  (November  1987):  20-26. 

Delisle,  Norman  and  Mayer  Schwartz.  "Contexts  — 
A  Partitioning  Concept  for  Hypertext."  Computer- 
Supported  Cooperative  Work  (CSCW  '86) 
Proceedings.  December  3-5,  Austin,  TX,  1986.  147- 
152. 

Delisle,  Norman  and  Mayer  Schwartz.  Neptune:  A 
Hypertext  System  for  CAD  Applications,  CR-85- 
50.  Tektronix  Computer  Research  Laboratory, 
Beaverton,  OR,  January  1986. 

DeRose,  Steven  J.  "Expanding  the  Notion  of  Links." 
Hypertext  '89  Proceedings.  November  5-7,  1989, 
Pittsburgh,  PA.  New  York:  ACM,  1989.  249-258. 

DeYoung,  Laura.  "Hypertext  Challenges  in  the 
Auditing  Domain."  Hypertext  '89  Proceedings. 
November  5-7,  1989,  Pittsburgh,  PA.  New  York: 
ACM,  1989. 169-180. 

diSessa,  Andrea  A.  "A  Principled  Design  for  an 
Integrated  Computational  Environment."  Human- 
Computer  InteracHon,  Vol.  1  (1985):  1-47. 


Hypermedia  Bibliography  NISI  Version 


-252- 


January  1990 


diSessa,  Andrea  A.  and  Harold  Abelson.  "Boxer:  A 
Reconstructable  Computational  Medium."  Com- 
munications of  the  ACM,  Vol.  29,  No.  9  (September, 
1986):  859-868. 

Doland,  Virginia  M.  "The  Hermeneutics  of 
Hypertext."  Proceedings  of  the  12th  International 
Online  Information  Meeting.  December  6-8,  1988, 
London,  England.  Oxford  and  New  Jersey:  Learned 
Information,  1988.  75-82. 

Doland,  Virginia  M.  "Hypermedia  as  an 
Interpretive  Act."  Hypermedia,  Vol.  1,  No.  1 
(Spring  1989):  6-19. 

Duffy,  Thomas  M.,  Brad  Mehlenbacher  and  Jim 
Palmer.  "The  Evaluation  of  Online  Help  Systems: 
A  Conceptual  Model."  in  The  Society  of  Text: 
Hypertext,  Hypermedia,  and  the  Social 
Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA:  Tl\e  MIT  Press,  1989.  362- 
387. 

Duncan,  Elizabeth  B.  "Structuring  Knowledge  Bases 
for  Designers  of  Learning  Materials."  Hypermedia, 
Vol.  1,  No.  1  (Spring  1989):  20-33. 

Duncan,  Elizabeth  B.  "A  Faceted  Approach  to 
Hypertext?"  in  Hypertext:  Theory  into  Practice, 
Ray  McAleese,  (editor).  Norwood,  NJ:  Ablex 
Publishing  Corporation,  1989. 157-163. 

Edwards,  Deborah  M.  and  Lynda  Hardman.  "'Lost 
in  Hyperspace':  Cognitive  Mapping  and 
Navigation  in  a  Hypertext  Environment."  in 
Hypertext:  Theory  into  Practice,  Ray  McAleese, 
(editor).  Norwood,  NJ:  Ablex  Publishing 
Corporation,  1989.  105-125. 

Egan,  Dennis  E.,  Joel  R.  Remde,.  Thomas  K. 
Landauer,  Carol  C.  Lockbaum  and  Louis  M.  Gomez. 
"Behavioral  Evaluation  and  Analysis  of  a 
Hypertext  Browser."  Proceedings  of  the  Annual 
Meeting  of  the  American  Educational  Research 
Association.  April  30-May  4,  1989,  Austin,  TX.  205- 
210. 

Egan,  Dennis  E.,  Joel  R.  Remde,  Louis  M.  Gomez, 
Thomas  K.  Landauer,  Jennifer  Eberhardt  and  Carol 
C.  Lochbaum.  "Formative  Design  Evaluation  of 
SuperBook."  ACM  Transactions  on  Information 
Systems,  Vol.  7,  No.  1  (January  1989):  30-57. 

Ehrlich,  K.  and  Janet  H.  Walker.  "High 
Functionality,  Information  Retrieval,  and  the 
Document  Examiner."  in  Personalized  Intelligent 
Information  Systems,  Report  on  a  Workshop 
(Breckenridge,  CO),  Fischer,  G.  and  H.  Nieper, 
(editors).  1987. 

Hypermedia  Bibliography  NIST  Version 


Engelbart,  Douglas  C.  "A  Conceptual  Framework 
for  the  Augmentation  of  Man's  Intellect."  in  Vistas 
in  Information  Handling,  Volume  I,  P.  D.  Howcrton 
and  D.  C.  Weeks,  (editors).  Washington,  D.C.: 
Spartan  Books,  1963.  1-29. 

Engelbart,  Douglas  C.  "Coordinated  Information 
Services  for  a  Discipline  or  Mission-Oriented 
Community."  Second  Annual  Computer  Com- 
munications Conference.  San  Jose,  CA,  January,  1973. 

Engelbart,  Douglas  C.  "Fesign  Considerations  for 
Knowledge  Workshop  Terminals."  AFIPS  Con- 
ference Proceedings  -  1973  National  Computer 
Conference  and  Exposition.  June  4-8,  1987,  New 
York,  NY.  Montvale,  NJ:  AFIPS  Press,  1973.  221- 
227. 

Engelbart,  Douglas  C.  "Toward  Integrated 
Evolutionar)^  Office  Automation  Systems."  Pro- 
ceedings of  the  International  Engineering  Man- 
agement Conference.  October  16-18,  Denver,  CO, 
1978. 

Engelbart,  Douglas  C.  "Evolving  the  Organization 
of  the  Future:  A  Point  of  View."  Emerging  Office 
Systems.  Robert  M.  Landau  and  James  H.  Blair, 
(editors),  1982.  287-297. 

Engelbart,  Douglas  C.  "Authorship  Provisions  in 
Augment."  Proceedings  of  the  1984  COMPCON 
Conference  (COMPCON  '84  Digest).  February  27- 
March  1,  1984,  San  Francisco,  CA.  IEEE  Computer 
Society  Press,  Spring,  1984.  465-472. 

Engelbart,  Douglas  C.  "Collaboration  Support 
Provisions  in  Augment."  Proceedings  of  the  AFIPS 
Office  Automation  Conference  (OAC  '84  Digest). 
February,  1984,  Los  Angeles,  CA,  1984. 51-58. 

Engelbart,  Douglas  C.  and  William  K.  English.  "A 
Research  Center  for  Augmenting  Human  Intellect." 
AFIPS  Conference  Proceedings,  1968  Fall  Joint 
Computer  Conference.  December  9-11,  1968,  San 
Francisco,  CA.  Montvale,  NJ:  AFIPS  Press,  Fall 
1968.  395-410. 

Engelbart,  Douglas  C.  with  Kristina  Hooper.  "The 
Augmentation  System  Framework."  in  Interactive 
Multimedia,  Sueann  Ambron  and  Kristina  Hooper, 
(editors).  Redmond,  WA:  Microsoft  Press,  1988.  15- 
32. 

Engelbart,  Douglas  C,  Richard  W.  Watson  and 
James  C.  Norton.  "The  Augmented  Knowledge 
Workshop."  AFIPS  Conference  Proceedings,  1973 
National  Computer  Conference  and  Exposition.  June 
4-8,  1973,  New  York,  NY.  Montvale,  NJ:  AFIPS 
Press,  1973.9-21. 

-253-  January  1990 


English,  William  K.,  Douglas  C.  Engelbart  and  M. 
L.  Berman.  "Display-Selection  Techniques  for  Text 
Manipulation/'  IEEE  Transactions  on  Human 
Factors  and  Electronics,  Vol.  8,  No.  1  (March  1967): 
5-15. 

Evenson,  Shelly,  John  Rheinfrank,  Fitch 
Richardsonsmith  and  Wendy  Wulff.  "Towards  a 
Design  Language  for  Representing  Hypermedia 
Cues."  Hypertext  '89  Proceedings.  November  5-7, 
1989,  Pittsburgh,  PA.  New  York:  ACM,  1989.  83-92. 

Fairchiid,  Kim  ¥.,  Steve  E.  Poltrock  and  George  W. 
Furnas,  "SemNet:  Three-dimensional  Graphic 
Representations  of  Large  Knowledge  Bases."  in 
Cognitive  Science  and  its  Applications  for  Human- 
Computer  Interaction,  R.  Guindon,  (editor). 
Hillsdale,  NJ:  Lawrence  Erlbaum  Associates,  in 
press. 

Feiner,  Steven.  "Interactive  Documents."  in  Design 
in  the  Information  Environment,  P.  Whitney  and  C. 
Kent,  (editors).  New  York:  Alfred  Knopf,  1985.  118- 
132. 

Feiner,  Steven.  "Seeing  the  Forest  for  the  Trees: 
Hierarchical  Display  of  Hypertext  Structure." 
Conference  on  Office  Information  Systems.  March 
23-25,  1988,  Palo' Alto,  CA.  New  York:  ACM.  205- 
212. 

Feiner,  Steven,  Sandor  Nagy  and  Andries  van  Dam, 
"An  Experimental  System  for  Creating  and 
Presenting  Interactive  Graphical  Documents."  ACM 
Transactions  on  Graphics,  Vol.  1,  No.  1  (January 
1982):  59-77. 

Feiner,  Steven,  Sandor  Nagy  and  Andries  van  Dam. 
"An  Integrated  System  for  Creating  and  Presenting 
Complex  Computer -Based  Documents."  Computer 
Graphics,  Vol.  15,  No.  3  (August  1981):  181-189. 

Feiner,  Steven,  Sandor  Nagy  and  Andries  van  Dam. 
"Online  Documents  Combining  Pictures  and  Texts." 
Proceedings  of  the  International  Conference  on 
Research  Trends  in  Document  Preparation  Systems. 
February  27-28,  Lausanne,  Switzerland.  Lausanne 
and  Zurich:  Swiss  Institutes  of  Technology,  1981.  1- 
4. 

Fischer,  Gerhard,  Raymond  McCall  and  Anders 
Morch.  "JANUS:  Integrating  Hypertext  with  a 
Knowledge-Based  Design  Environment."  Hypertext 
'89  Proceedings.  November  5-7,  1989,  Pittsburgh, 
PA.  New  York:  ACM,  1989. 105-118. 


Fish,  Robert  S.,  Robert  E.  Kraut,  Mary  D.  P.  Leland 
and  Michael  Cohen.  "Quilt:  A  Collaborative  Tool 
for  Cooperative  Writing."  ACM  SIGOIS  Bulletin. 
Robert  B.  Allen,  (editor).  (March  1988):  30-37. 

Foss,  Carolyn  L.  "Effective  Browsing  in  Hypertext 
Systems."  Proceedings  of  the  Conference  on  User- 
Oriented  Content-Based  Text  and  Image  Handling 
(RIAO  88).  March  21-24,  MIT,  Cambridge  MA. 
Centre  de  Hautes  Etudes  Internationales 
d'informatique  Documentaire,  1988.  83-98. 

Foster,  Edward.  "Outliners:  A  New  Way  of 
Thinking."  Personal  Computing,  (May,  1985):  74. 

Foster,  Gregg  and  Mark  Stefik.  "Cognoter,  Theor}' 
and  Practice  of  a  Collaborative  Tool."  Computer- 
Supported  Cooperative  Work  (CSCW  '86)  Pro- 
ceedings. December  3-5,  Austin,  TX,  1986.  7-15. 

Frisse,  Mark.  "From  Text  to  Hypertext."  Byte, 
(October  1988):  247-253. 

Frisse,  Mark  E.  "Searching  for  Information  in  a 
Hypertext  Medical  Handbook."  Communications  of 
the  ACM,  Vol.  31,  No.  7  (July  1988):  880-886. 

Frisse,  Mark  E.  and  Steve  B.  Cousins.  "Information 
Retrieval  from  Hypertext:  Update  on  the  Dynamic 
Medical  Handbook  Project."  Hypertext  '89 
Proceedings.  November  5-7,  1989,  Pittsburgh,  PA. 
New  York:  ACM,  1989.  199-212. 

Furuta,  Richard  and  P.  David  Stotts. 
"Programmable  Browsing  Semantics  in  Tellis." 
Hypertext  '89  Proceedings.  November  5-7,  1989, 
Pittsburgh,  PA.  New  York:  ACM,  1989.  27-42. 

Garg,  Pankaj  K.  "Abstraction  Mechanisms  in  Hy- 
pertext." Communications  of  the  ACM,  Vol.  31,  No. 
7  (July  1988):  862-870. 

Garg,  Pankaj  K.  and  Walt  Scacchi.  "Composition  of 
Hypertext  Nodes."  Proceedings  of  the  11th 
International  Online  Information  Meeting.  De- 
cember 6-8, 1988,  London,  England.  Oxford  and  New 
Jersey:  Learned  Information,  1988.  63-73. 

Garg,  Pankaj  K.  and  Wait  Scacchi.  "A  Hypertext 
System  to  Manage  Software  Life  Cycle  Documents." 
7.1st  Hawaii  International  Conference  on  Systems. 
Honolulu  HI,  1987. 

Garg,  Pankaj  K.  and  Walt  Scacchi,  "On  Designing 
Intelligent  Hypertext  Systems  for  information 
Management  in  Software  Engineering."  Hypertext 
'87  Papers.  November  13-15,  1987,  Chapel  Hill, 
NC.  New  York:  ACM,  1989.  409-432. 


Hypermedia  Bibliography  NISI  Version 


-254- 


January  1990 


Garrett,  L.  Nancy  and  Karen  E.  Smith.  "Building  a 
Timeline  Editor  from  Prefab  Parts:  The  Ar- 
chitecture of  an  Object-oriented  Application." 
Proceedings  of  the  Conference  on  Object-Oriented 
Programming  Systems,  Languages  and  Applications 
(OOPSLA  '86).  September  29-October  2,  Portland, 
Oregon,1986.  202-213. 

Garrett,  L.  Nancy,  Karen  E.  Smith  and  Norman 
Meyrowitz.  "Intermedia:  Issues,  Strategies,  and 
Tactics  in  the  Design  of  a  Hypermedia  Document 
System."  Computer- Supported  Cooperative  Work 
(CSCW  '86)  Proceedings.  December  3-5,  Austin,  TX, 
1986.  163-174. 

Gaulding,  Jill  and  Boris  Katz.  "Using  'Word- 
Knowledge'  Reasoning  for  Question  Answering."  in 
The  Society  of  Text:  Hypertext,  Hypermedia,  and 
the  Social  Construction  of  Information,  Edward 
Barrett,  (editor).  Cambridge,  MA:  The  MIT  Press, 
1989.  403-422. 

Glushko,  Robert  J.  "Design  Issues  for  Multi- 
Document  Hypertexts."  Hypertext  '89  Proceedings. 
November  5-7,  1989,  Pittsburgh,  PA.  New  York: 
ACM,  1989.  51-60. 

Glushko,  Robert  J.,  M.  D.  Weaver,  T.  A.  Coonan  and 
}.  E.  Lincoln.  "Hypertext  Engineering:  Practical 
Methods  for  Creating  a  Compact  Disc  En- 
cyclopedia." Proceedings  of  the  ACM  Conference  on 
Document  Processing  Systems.  December  5-9,  1988, 
Santa  Fe,  New  Mexico.  New  York:  ACM,  1988.  11- 
19. 

Goodman,  Danny.  The  Complete  HyperCard  Hand- 
book. New  York:  Bantam  Books,  1987. 

Greenes,  Robert  A.  "Knowledge  Management  as  an 
Aid  to  Medical  Decision  Making  and  Education: 
The  Explorer-1  System."  Proceedings  MEDINFO 
'86.  Elsevier  Science  Publishers  B.V.,  1986.  895-899. 

Greenes,  Robert  A.  "Toward  More  Effective 
Radiologic  Consultation:  Design  of  a  Desktop 
Workstation  to  Aid  in  the  Selection  and  In- 
terpretation of  Diagnostic  Procedures."  Proceedings 
Eighth  Conference  on  Computer  Applications  in 
Radiology.  May  1984,  St.  Louis,  MO.  553-562. 

Gregory,  Roger.  "Xanadu — Hypertext  from  the 
Future."  Dr.  Dobb's  Journal,  No.  75  (January,  1983): 
28-35. 


Grico,  Roger  A.  "Online  Information:  What  Do 
People  Want?  What  Do  People  Need?"  in  The 
Society  of  Text:  Hypertext,  Hypermedia,  and  the 
Social  Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA;  The  MIT  Press,  1989.  22- 
44. 

Gullichsen,  Eric,  D.  D'Souza,  P.  Lincoln  and  T. 
Casey.  The  PlaneTextBook,  STP-333-86(P).  MCC 
Software  Technology  Program,  Austin,  TX,  1986. 

Halasz,  Frank  G.  ""NoleCards:  A  Multimedia  Idea 
Processing  Environment."  in  Interactive  Mul- 
timedia, Sueann  Ambron  and  Kristina  Hooper, 
(editors).  Redmond,  Vv'A:  Microsoft  Press,  1988.  105- 
110. 

Halasz,  Frank  G.  "Reflections  on  Notecards:  Seven 
Issues  for  the  Next  Generation  of  Hypermedia 
Systems."  Communications  of  the  ACM,  Vol.  31, 
No.  7  (July  1988):  836-855. 

Halasz,  Frank  G.,  Thomas  P.  Moran  and  Randall  H. 
Trigg.  "NoteCards  in  a  Nutshell."  Proceedings  of 
the  CHI  and  GI  '87  Conference  on  Human  Factors  in 
Computing  Systems.  J.  M.  Carroll  and  P.  P.  Tanner, 
(editors).  April  1987,  Toronto.  New  York:  ACM, 
1987.  45-52. 

Hammvi/ohner,  Rainer  and  Ulrich  Thiel.  "Content- 
Oriented  Relations  Between  Text  Units — A  Struc- 
tural Model  for  Hypertexts."  Hypertext  '87  Papers. 
November  13-15,  1987,  Chapel  Hill,  NC.  New 
York:  ACM,  1989. 155-174. 

Hardman,  Lynda.  "Evaluating  the  Usability  of  the 
Glasgow  Online  Hypertext."  Hypermedia,  Vol.  1, 
No.  1  (Spring  1989):  34-63. 

Harland,  J.S.  "Human  Factors  Engineering  and 
Interface  Development:  A  Hypertext  Tool  Aiding 
Prototyping  Activity."  in  Hypertext:  Theory  into 
Practice,  Ray  McAleese,  (editor).  Norwood,  NJ: 
Ablex  Publishing  Corporation,  1989. 126-137. 

Harvey,  Greg.  Understanding  HyperCard.  Alame- 
da, CA:  SYBEX,  Inc.,  1988. 

Hayes,  Phil  and  Jeff  Pepper.  "Towards  an 
Integrated  Maintenance  Advisor."  Hypertext  '89 
Proceedings.  November  5-7,  1989,  Pittsburgh,  PA. 
New  York:  ACM,  1989. 119-128. 

Herot,  C,  R.  Carling,  M.  Friedell  and  D.  Kramlich. 
"A  Prototype  Spatial  Data  Management  System." 
Computer  Graphics,  Vol.  14,  No.  3  (July  1980):  63- 
70. 


Hypermedia  Bibliography  NISI  Version 


-255- 


January  1990 


Herrstrom,  David  S.  and  David  G.  Massey. 
"Hypertext  in  Context."  in  The  Society  of  Text: 
Hypertext,  Hypermedia,  and  the  Social  Con- 
struction of  Information,  Edv^ard  Barrett,  (editor). 
Cambridge,  MA:  The  MIT  Press,  1989. 45-58. 

Hershey,  William.  "Software  Review:  Idea 
Processors."  Byte,  Vol.  10,  No.  6  (June,  1985):  337- 
350. 

Hiltz,  Starr  Roxarme.  "The  'Virtual  Classroom': 
Using  Computer-Mediated  CornmianicaHon  for 
University  Teaching."  Journal  of  Communication, 
(Spring,  1968):  95-104. 

Hiltz,  Starr  Roxanne  and  Murray  Turoff.  The 
Network  Nation:  Human  Communication  via 
Computer.  Reading,  MA:  Addison-Wesley  Pub- 
lishing Company,  Inc.,  1978. 

Hjerppe,  Roland.  "Hypercatalog  and  Three  Meta- 
Schemata  for  Database  Views:  Knowledge  Or- 
ganizing, Collection  Derived,  and  User  Established 
Structures."  Online  Public  Access  to  Library  Files: 
Second  National  Conference.  Janet  Kinsella, 
-  (editor).  Elsevier  International  Bulletins.  101-110. 

Hjerppe,  Roland.  "Project  HYPERCATalog:  Visions 
and  Preliminary  Conceptions  of  an  Extended  and 
Enhanced  Catalog."  in  Intelligent  Information 
Systems  for  the  Information  Society,  B.  C.  Brookes, 
(editor).  Amsterdam:  Elsevier  Science  Publishers, 
1986.  211-232. 

Hodges,  Matthew  E.,  Ben  H.  Davis  and  Russell  M. 
Sasnett.  "Investigations  in  Multimedia  Design 
Documentation."  in  The  Society  of  Text:  Hypertext, 
Hypermedia,  and  the  Social  Construction  of 
Information,  Edward  Barrett,  (editor).  Cambridge, 
MA:  The  MIT  Press,  1989.  79-89. 

Irby,  Charles  H.  "Display  Techniques  for  In- 
teractive Text  Manipulation."  AFIPS  Conference 
Proceedings  — 1974  National  Com.puter  Conference 
and  Exposition.  May  6-10,  1974,  Chicago,  IL. 
Montvale,  NJ:  AHPS  Press.  247-255. 

Irish,  Peggy  M.  and  Randall  H.  Trigg.  "Supporting 
Collaboration  in  Hypermedia:  Issues  and 
Experiences."  in  The  Society  of  Text:  Hypertext, 
Hypermedia,  and  the  Social  Construction  of 
Information,  Edward  Barrett,  (editor).  Cambridge, 
MA:  The  MIT  Press,  1989.  90-106. 

Jaffe,  Conrade  C,  Patrick  J.  Lynch  and  Arnold  W. 
M.  Smeulders.  "Hypermedia  Techniques  for  Di- 
agnostic Imaging  Instniction:  Videodisk  Echocar- 
diography Encyclopedia."  Radiology,  Vol.  117,  No. 
2  (May  1989):  475-80. 

Hypermedia  Bibliography  NISI  Version 


Jaynes,  Joseph  T.  "Limited  Freedom:  Linear 
Reflections  on  Nonlinear  Texts."  in  The  Society  of 
Text:  Hypertext,  Hypermedia,  and  the  Social 
Construction  of  Information,  Edward  Barrett^ 
(editor).  Cambridge,  MA:  The  MIT  Press,  1989. 148- 
161. 

Jonassen,  D.  H.  "Hypertext  Principles  for  Text  and 
Courseware  Design."  Educational  Psychologist, 
Vol.  21  (1986):  269-292. 

Jones,  Henry  V*/.,  III.  "Developing  and  Distributing 
Hypertext  Tools:  Legal  Inputs  and  Parameters." 
Hypertext  '87  Papers.  November  13-15,  1987, 
Chapel  Hill,  NC.  New  York:  ACM,  1989.  367-374. 

Jones,  William  P.  "How  Do  We  Distinguish  the 
Hyper  from  the  Hype  in  Non-linear  Text?" 
INTERACT  '87.  H.  J. 

and  B.  Shackel,  (editors).  September  1-4,  1987, 
Stuttgart.  Elsevier  Science  Publishers  B.V.,  1987. 
1107-1113. 

Jordan,  Daniel  S.,  Daniel  M.  Russell,  Anne-Marie  S. 
Jensen  and  Russel  A.  Rogers.  "Facilitating  the 
Development  of  Representations  in  Hypertext  with 
IDE."  Hypertext  '89  Proceedings.  November  5-7, 
1989,  Pittsburgh,  PA.  New  York:  ACM,  1989.  93-104. 

Kacmar,  Charles  J.  "A  Process-Oriented  Extensible 
Hypertext  Architecture."  SIGCHI  Bulletin,  Vol. 
21,  No.  1  (July  1989):  98-101. 

Kahn,  Paul.  "Information  Retrieval  As 
Hypermedia:  An  Outline  of  InterBrowse." 
Proceeding  of  the  Ninth  National  Online  Meeting. 
May  10-12,  New  York.  New  York:  Learned 
Information,  1988. 131-139. 

Kahn,  Paul.  "Linking  Together  Books:  Experiments 
in  Adapting  Published  Material  into  Intermedia 
Documents."  Hypermedia,  Vol.  1,  No.  2  (Summer 
1989):  111-144. 

Kahn,  Paul  and  Norman  Meyrowitz.  "Guide, 
HyperCard,  and  Intermedia:  A  Comparison  of 
Hypertext/ Hypermedia  Systems."  IRIS  Technical 
Report,  88-7.  Brown  University,  Providence  RI, 
1988. 

Kay,  Alan  C.  "Computer  Software."  Scientific 
American,  Vol.  251,  No.  3  (September,  1984):  53-59. 

Kay,  Alan  C.  Personal  Dynamic  Media,  Xerox 
PARC  Technical  Report  SSL-76-1.  Xerox  Palo  Alto 
Research  Center,  Palo  Alto  CA,  March  1976. 


_256-  January  1990 


Kelly,  Kirk.  "Online  Citation  Maintenance  for 
Literature  Publication  and  Retrieval  over  Com- 
puter Networks."  Teleinformatics  79.  Boutmy  and 
Danthi  ne,  (editors).  North-Holland  Publishing 
Company,  1979. 

Kerr,  Elaine  and  Starr  Roxanne  Hiltz.  Computer- 
Mediated  Communication  Systems.  New  York: 
Academic  Press,  1982. 

Kibby,  M.R.  and  T.  Mayes.  "Towards  Intelligent 
Hypertext."  in  Hypertext:  Theory  into  Practice, 
Ray  McAleese,  (editor).  Norwood,  NJ:  Ablex 
Publishing  Corporation,  1989. 164-172. 

Kochen,  Manfred.  "WISE:  A  World  Information 
Synthesis  and  Encyclopedia."  Journal  of  Doc- 
umentation, Vol.  28  (1972):  322-343. 

Koo,  Richard.  "A  Model  for  Electronic  Documents." 
ACM  SIGOIS  Bulletin.  Simon  Gibbs,  (editor). 
(January  1989):  23-33. 

Koved,  Larry.  Restructuring  Textual  Information  for 
Online  Retrieval,  Technical  Report  11278(#50830). 
IBM  T.J.  Watson  Research  Center,  Yorktown 
Heights,  NY,  July  23,  1985. 

Kunkel,  Paul.  "Hyper  Media."  International 
Design,  (March/ April  1989):  41-43. 

Lambert,  Steve  and  Suzanne  Ropiequet.  CD  ROM: 
The  New  Papyrus.  Redmond,  WA:  Microsoft  Press, 
1986. 

Landow,  George  P.  "Context32:  Using  Hypermedia 
to  Teach  Literature."  Proceedings  of  the  1987  IBM 
Academic  Information  Systems  University  AEP 
Conference.  Milford,  Connecticut:  IBM  Academic 
Information  Systems,  1987. 

Landow,  George  P.  Course  Assignments  Using 
Hypertext:  The  Example  of  Intermedia,  IRIS, 
Brown  University,  Providence,  RI,  1988. 

Landow,  George  P.  "Hypertext  in  Literary  Ed- 
ucation, Criticism,  and  Scholarship."  Computers 
and  the  Humanities,  Vol.  23  (July  1988):  173-198. 

Landow,  George  P.  "Relationally  Encoded  Links 
and  the  Rhetoric  of  Hypertext."  Hypertext  '87 
Papers.  November  13-15,  1987,  Chapel  Hill,  NC. 
New  York:  ACM,  1989.  331-344. 

Landow,  George  P.  "The  Rhetoric  of  Hypermedia: 
Some  Rules  for  Authors."  Journal  of  Computing  in 
Higher  Education,  Vol.  1,  No.  1  (Spring  1989):  39- 
64. 


Lenat,  Douglas  B.,  Alan  M.  Borning,  D.  McDonald, 
C.  Taylor  and  Stephen  A.  Weyer.  "Knoesphcre: 
Building  Expert  Systems  with  Encyclopedic  Knowl- 
edge." Proceedings  of  the  8th  International  Joint 
Conference  on  Artificial  Intelligence.  Karlsruhe, 
West  Germany,  1983. 167-169. 

Lesk,  Michael.  "What  to  Do  When  There's  Too 
Much  Information."  Hypertext  '89  Proceedings. 
November  5-7,  1989,  Pittsburgh,  PA.  New  York: 
ACM,  1989.  305-318. 

Lewis,  Brian  T.  and  Jeffrey  D.  Hodges.  "Shared 
Books:  Collaborative  Publication  Management  for 
an  Office  InformaHon  System."  COIS  88.  March  23- 
25,  1988,  Palo  Alto,  CA.  New  York:  ACM,  1988. 197- 
204. 

Louie,  Steven  and  Robert  F.  Rubeck.  "Hypertext 
Publishing  and  the  Revitalization  of  Knowledge." 
Academic  Computing,  Vol.  3,  No.  9  (May  1989):  20- 
23,  30-31. 

Lowe,  David  G.  "SYNVIEW:  The  Design  of  a 
System  for  Cooperative  Structuring  of  Information." 
Computer-Supported  Cooperative  Work  (CSCW 
'86)  Proceedings.  December  3-5,  Austin,  TX,  1986. 
376-386. 

Luther,  Willis  and  Martin  Carter.  Management  of 
Change  and  History  in  a  Hypermedia  Environment, 
MCC  Technical  Report  HI-1 64-87.  June  1987. 

Malone,  Thomas  W.,  Kenneth  R.  Grant,  Franklyn 
A.  Turbak,  Stephen  Brobst  and  Michael  D.  Cohen. 
"Intelligent  Information-Sharing  Systems."  Com- 
munications of  the  ACM,  Vol.  30,  No.  5  (May  1987): 
390-402. 

Mantei,  Marilyn  and  Donald  L.  McCracken.  "Issue 
Analysis  with  ZOG,  A  Highly  Interactive  Man- 
Machine  Interface."  Proceedings  of  the  First 
International  Symposium  on  Policy  Analysis  and 
Information  Systems,  1979. 

Marchionini,  Gary.  "Hypermedia  and  Learning: 
Freedom  and  Chaos."  Educational  Technology,  Vol. 
27,  No.  11  (1988):  8-12. 

Marchionini,  Gary  and  Ben  Shneiderman.  "Finding 
Facts  and  Browsing  Knowledge  in  Hypertext 
Systems."  IEEE  Computer,  Vol.  21,  No.  1  (January 
1988):  70-79. 

Marshall,  Catherine  C.  "Exploring  Representation 
Problems  Using  Hypertext."  Hypertext  '87  Papers. 
November  13-15,  1987,  Chapel  Hill,  NC.  New 
York:  ACM,  1989.  253-268. 


Hypermedia  Bibliography  NiST  Version 


-257- 


January  1990 


Marshall,  Catherine  C.  and  Peggy  Irish.  "Guided 
Tours  and  On-Line  Presentations:  How  Authors 
Make  Existing  Hypertext  Intelligible  for  Readers." 
Hypertext  '89  Proceedings.  November  5-7,  1989, 
Pittsburgh,  PA.  New  York:  ACM,  1989. 15-26. 

Maxemchuck,  Nick  F.  and  H.  A.  Wilder.  "Virtual 
Editing:  I.  The  Concept."  Proceedings  of  the  Second 
International  Workshop  on  Office  Information 
Systems.  October  13-15,  1982,  Couvent  Royal  de  St. 
Maximin.  New  York:  Elsevier  North-Holland, 
1982. 

McAleese,  Ray.  Hypertext:  Theory  into  Practice. 
Norwood,  New  Jersey:  Ablex  Publishing  Cor- 
poration, 1989. 

McAleese,  Ray.  "Navigation  and  Browsing  in 
Hypertext."  in  Hypertext:  Theory  into  Practice, 
Ray  McAleese,  (editor).  Norwood,  NJ:  Ablex 
Publishing  Corporation,  1989.  6-44. 

McCracken,  Donald  L.  and  Robert  M.  Akscyn. 
"Experience  with  the  ZOG  Human-Computer 
Interface  System."  International  Journal  of  Man- 
Machine  Studies,  Vol.  21,  No.  2  (1984):  293-310. 

McCracken,  Donald  L.  and  Robert  Akscyn.  The  ZOG 
Approach  to  Database  Management,  CS-34-113. 
Carnegie-Mellon  University,  Pittsburgh,  PA. 

McKnight,  Cliff,  John  Richardson  and  Andrew 
Dillon.  "The  Authoring  of  HyperText  Documents." 
in  Hypertext:  Theory  into  Practice,  Ray  McAleese, 
(editor).  Norwood,  NJ:  Ablex  Publishing 
Corporation,  1989.  138-147. 

Meyrowitz,  Norman.  "Intermedia:  The  Ar- 
chitecture and  Construction  of  an  Object-Oriented 
Hypertext/Hypermedia  System  and  Applications 
Framework."  Proceedings  of  the  Conference  on 
Object-Oriented  Programing  Systems,  Languages, 
and  Applications  (OOPSLA  '86).  September  29- 
October  2,  Portland,  Oregon,  1986. 

Meyrowitz,  Norman.  "The  Missing  Link:  Why 
We're  All  Doing  Hypertext  Wrong."  in  The  Society 
of  Text:  Hypertext,  Hypermedia,  and  the  Social 
Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA:  The  MIT  Press,  1989.  107- 
114. 

Meyrowitz,  Norman.  Networks  of  Scholar's 
Workstations:  End-User  Computing  in  a  University 
Community,  Technical  Report  85-3.  IRIS,  Brown 
University,  Providence,  RI,  June  1985. 

Michel,  Stephen.  "Guide  —  A  Hypertext  Solution." 
CD-ROM  Review,  (July/ August  1987):  22-24. 

Hypermedia  Bibliography  NISI  Version 


Monty,  Melissa  L.  "Temporal  Context  and  Memory 
for  Notes  Stored  in  the  Computer."  ACM  SIGCHI 
Bulletin,  Vol.  18,  No.  2  (October,  1986):  50-51. 

Monty,  Melissa  L.  and  Thomas  P.  Moran.  "A 
Longitudinal  Study  of  Authoring  Using  Note- 
Cards."  ACM  SIGCHI  Bulletin,  Vol.  18,  No.  2 
(October,  1986):  59-60. 

Morariu,  Janis.  "Hypermedia  in  Instruction  and 
Training:  The  Power  and  the  Promise."  Educational 
Technology,  Vol.  27,  No.  11  (1988):  17-20. 

Moulthrop,  Stuart.  "Hypertext  and  'the 
Hyperreal'."  Hypertext  '89  Proceedings.  November 
5-7,  1989,  Pittsburgh,  PA.  New  York:  ACM,  1989. 
259-268. 

Negroponte,  Nicholas.  "Books  Without  Pages." 
IEEE  International  Conference  on  Communications 
IV,  1979. 

Negroponte,  Nicholas.  "An  Idiosyncratic  Systems 
Approach  to  Interactive  Graphics." 
ACM/SIGGRAPH  Workshop  on  User-Oriented  De- 
sign of  Interactive  Graphics  Systems.  Pittsburgh, 
PA,  October,  1976. 

Nelson,  Theodor  H.  "The  Hypertext."  2  965 
Congress  of  the  International  Federation  for 
Documentation  (FID)  Abstracts.  10-15  October  1965, 
Washington  DC.  80. 

Nelson,  Theodor  H.  "A  File  Structure  for  the 
Complex,  the  Changing  and  the  Indeterminate." 
Association  for  Computing  Machinery,  Proceedings 
of  the  National  Conference,  20th.  New  York:  ACM, 
1965.  84-100. 

Nelson,  Theodor  H.  "Getting  it  Out  of  Our  System." 
in  Information  Retrieval:  A  Critical  View,  G. 
Schecter,  (editor).  Washington,  D.C.:  Thompson 
Book  Co.,  1967. 191-210. 

Nelson,  Theodor  H.  "As  We  Will  Think."  Online 
72:  Conference  Proceedings  of  the  International 
Conference  on  Online  Interactive  Computing. 
September,  1972,  Brunei  University,  Uxbridge, 
England.  Uxbridge,  England:  Online  Computer 
Systems  Ltd,  1973.  439-454. 

Nelson,  Theodor  H.  "A  Conceptual  Framework  for 
Man-Machine  Everything."  AFIPS  Conference 
Proceedings — 2973  National  Computer  Conference 
and  Exposition,  Proceedings.  June  4-8,  1973,  New 
York,  NY.  Montvale,  NJ:  AHPS  Press,  1973.  M21- 
M26. 


-258-  January  1990 


Nelson,  Theodor  H.  "Dream  Machines:  New 
Freedoms  through  Computer  Screens — A  Minority 
Report."  in  Computer  Lib:  You  Can  and  Must 
Understand  Computers  Now,  Redmond,  WA: 
Microsoft  Press,  1987. 

Nelson,  Theodor  H.  "Replacing  the  Printed  Word: 
A  Complete  Literary  System."  in  Information 
Processing  80,  S.H.  Lavington,  (editor).  North- 
Holland  Publishing  Co.,  IFIO  1980.  1013-1023. 

Nelson,  Theodor  H.  Literary  Machines.  Swarth- 
more,  PA:  T.H.  Nelson,  1981. 

Nelson,  Theodor  H.  "A  New  Home  for  the  Mind." 
Datamation,  (March,  1982):  169-180. 

Nelson,  Theodor  H.  "Managing  Immense  Storage." 
Byte,  (January  1988):  225-238. 

Nelson,  Theodor  H.  "All  for  One  and  One  for  All." 
Hypertext  '87  Papers.  November  13-15,  1987, 
Chapel  Hill,  NC.  New  York:  ACM,  1989.  v-vii. 

Nelson,  Theodor  H.  "Unifying  Tomorrow's 
Hypermedia."  Proceedings  of  the  12th  In- 
ternational Online  Information  Meeting.  December 
6-8, 1988,  London,  England.  Oxford  and  New  Jersey: 
Learned  Information,  1988.  1-7. 

Neuwirth,  Christine  M.  "Techniques  of  User 
Message  Design:  Developing  a  User  Message 
System  to  Support  Cooperative  Work."  in  The 
Society  of  Text:  Hypertext,  Hypermedia,  and  the 
Social  Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA:  The  MIT  Press,  1989.  325- 
342. 

Neuwirth,  Christine,  David  Kaufer,  Rick  Chimera 
and  Terilyn  Gillespie.  "The  Notes  Program:  A 
Hypertext  Applications  for  Writing  from  Source 
Texts."  Hypertext  '87  Papers.  November  13-15, 
1987,  Chapel  Hill,  NC.  New  York:  ACM,  1989.  121- 
141. 

Neuwirth,  Christine  M.  and  David  S.  Kaufer.  "The 
Role  of  External  Representation  in  the  Writing 
Process:  Implications  for  the  Design  of  Hypertext- 
Based  Writing  Tools."  Hypertext  '89  Proceedings. 
November  5-7,  1989,  Pittsburgh,  PA.  New  York: 
ACM,  1989.  319-342. 

Newell,  Alan,  Donald  L.  McCracken,  C.  Kamila 
Robertson  and  Robert  M.  Akscyn.  "ZOG  and  the 
USS  CARL  VINSON."  Computer  Science  Research 
Review,  (1981):  95-118. 


Hypermedia  Bibliography  NiST  Version 


Nguyen,  L.  T.  and  Robert  A.  Greenes.  "A  Framework 
for  the  Use  of  Computed  Links  in  the  EXPLORER-1 
Knowledge  Management  System."  in  MEDINFO  86, 
IFIP-IMIA,  R.  Salamon,  B.  Blum  and  M.  Jorgcnscn, 
(editors).  North-Holland:  Elsevier  Science 
Publishers  B.V.,  1986.  891-894. 

Nielsen,  Jakob.  "Evaluating  Hypertext  Usability." 
Proceedings  of  NATO  Advanced  Research 
Workshop  on  Designing  Hypertext/Hypermedia 
for  Learning.  July  4-7,  1989,  Rottenburg,  West 
Germany. 

Nielsen,  Jakob.  "Online  Documentation  and  Reader 
Annotation."  Proceedings  1st  International 
Conference  on  Work  with  Display  Units.  May  12- 
15,  1986,  Stockholm,  Sweden.  526-529. 

Nielsen,  Jakob.  "Prototyping  User  Interfaces  Using 
an  Object-Oriented  Hypertext  Programming 
System."  Proceedings  of  the  NordDATA'89  Joint 
Scandinavian  Computer  Conference.  June  19-22, 
1989,  Copenhagen,  Denmark. 

Nielsen,  Jakob  and  U.  Lyngboek.  "Two  Field  Studies 
of  Hypermedia  Usability."  Proceedings  of 
Hypertext  2  Conference.  June  29-30,  1989,  York,  UK. 

Nielson,  Jakob.  "The  Matters  that  Really  Matter 
for  Hypertext."  Hypertext  '89  Proceedings. 
November  5-7,  1989,  Pittsburgh,  PA.  New  York: 
ACM,  1989.  239-248. 

Nyce,  James  M.  and  Paul  Kahn.  "Innovation, 
Pragmaticism,  and  Technological  Continuity: 
Vannevar  Bush's  Memex."  Journal  of  American 
Society  for  Information  Science,  Vol.  40,  No.  3  (May 
1989):  214-220. 

Oren,  Tim.  "The  Architecture  of  Hypertexts." 
Hypertext  '87  Papers.  November  13-15,  1987, 
Chapel  Hill,  NC.  New  York:  ACM,  1989.  291-306. 

Palay,  Andrew  J.  and  Mark  S.  Fox.  "Browsing 
through  Databases."  in  Information  Retrieval 
Research,  R.  N.  Oddy,  (editor).  London: 
Butterworths,  1981.  310-324. 

Parunak,  H.  Van  Dyke.  "Hypermedia  Topologies 
and  User  Navigation."  Hypertext  '89  Proceedings. 
November  5-7,  1989,  Pittsburgh,  PA.  New  York: 
ACM,  1989.  43-50. 

Pasquier-Boltuck,  Jacques,  G.  Collaud  and  J. 
Monnard.  "An  Object-Oriented  Approach  to 
Conceptualizing  and  Programming  an  Interactive 
System  for  the  Creation  and  Consultation  of 
Electronic  Books."  WOODMAN  '89.  May  24-31, 
1989,  Pennes-France. 

-259-  January  1990 


Pasquier-Boltuck,  Jacques,  Edward  Grossman  and  G. 
Collaud.  "Prototyping  an  Interactive  Electronic 
Book  System  Using  an  Object-Oriented  Approach." 
Proceedings  of  ECOOP  '88.  Spring  1988. 

Pearl,  Amy.  "Sun's  Link  Service:  A  Protocol  for 
Open  Linking."  Hypertext  '89  Proceedings.  Novem- 
ber 5-7,  1989,  Pittsburgh,  PA.  New  York:  ACM, 
1989.  137-146. 

Perlman,  Gary.  "Asynchronous  Design/ Evaluation 
Methods  for  Hypertext  Technology  Development." 
Hypertext  '89  Proceedings.  November  5-7,  1989, 
Pittsburgh,  PA.  New  York:  ACM,  1989.  61-82. 

Perry,  T.  S.  "Hypermedia:  Finally  Here."  IEEE 
Spectrum,  Vol.  24,  No.  11  (1987):  38-39. 

Pontecorvo,  Michael  S.  'Idea  Processing  -  Concepts, 
Extensions  and  Applications."  Sperry  Technology 
Symposium  Proceedings.  May  1986,  Gull  Lake,  MN. 

Pontecorvo,  Michael  S.  An  Idea  Processing 
Approach  to  the  Development  of  Knowledge-Based 
Systems,  Technical  Report  No.  18376.  Sperry 
Communications  Corporate  Technology  Center,  Salt 
Lake  City,  UT,  March  1986. 

Pontecorvo,  Michael  S.  and  J.  J.  Krohnfeldt.  "A 
Knowledge-Based  Software  Development  Environ- 
ment for  the  Support  of  Rapid  Prototyping."  Univac 
Technology  Review,  Vol.  13  (May  1987): 

Potter,  Richard  L.,  Mitchell  Berman  and  Ben 
Shneiderman.  An  Experimental  Evaluation  of 
Three  Touchscreen  Strategies  within  a  Hypertext 
Database,  CS-TR-2141.  University  of  Maryland 
Computer  Science  Center,  College  Park,  MD, 
November  1988. 

Potts,  Colin  and  Glenn  Bruns.  "Recording  the 
Reasons  for  Design  Decisions."  Proceedings  10th 
International  Conference  on  Software  Engineering. 
IEEE  Computer  Society  Press,  1988. 

Price,  Lynne  A.  "Thumb:  An  Interactive  Tool  for 
Accessing  and  Maintaining  Text."  IEEE  Transactions 
on  Systems,  Man,  and  Cybernetics,  March/April, 
1982.  155-162. 

Rada,  Roy.  "Writing  and  Reading  Hypertext:  An 
Overview."  Journal  of  American  Society  for 
Information  Science,  Vol.  40,  No.  3  (May  1989):  164- 
171. 

Ragland,  Craig.  "Hypertext,  Hypermedia,  and  the 
Macintosh."  Mac  A. P. P. I.E.,  (August,  1987). 


Hypermedia  Bibliography  NISI  Version 


Ramakrishna,  K.  "Schematization  as  an  Aid  to 
Organizing  ZOG  Information  Nets."  Computer 
Science  Department,  Carnegie-Mellon  University, 
1981. 

Ramey,  Judith.  "Escher  Effects  in  Online  Text."  in 
The  Society  of  Text:  Hypertext,  Hypermedia,  and 
the  Social  Construction  of  Information,  Edward 
Barrett,  (editor).  Cambridge,  MA:  The  MIT  Press, 
1989.  388-402. 

Raskin,  Jef.  "The  Hype  in  Hypertext:  A  Critique." 
Hypertext  '87  Papers.  November  13-15,  1987, 
Chapel  Hill,  NC.  New  York:  ACM,  1989.  325-330. 

Raymond,  Darrell  R.  Personal  Data  Structuring  in 
Videotex,  CS-84-7.  University  of  Waterloo,  De- 
partment of  Computer  Science  Technology, 
February,  1984. 

Raymond,  Darrell  R.  and  Frank  Wm  Tompa. 
"Hypertext  and  the  Oxford  English  Dictionary." 
Communications  of  the  ACM,  Vol.  31,  No.  7  (July 
1988):  871-879. 

Reitman,  Walter,  Bruce  Roberts,  Richard  W. 
Sauvain,  Daniel  D.  Wheeler  and  William  Linn. 
"AUTONOTE  -  A  Personal  Information  Storage  and 
Retrieval  System."  Proceedings  of  the  24th 
National  Conference  of  the  ACM.  August  26-28, 
1969,  New  York:  ACM,  1969.  67-75. 

Remde,  Joel  R.,  Louis  M.  Gomez  and  Thomas  K. 
Landauer.  "SuperBook:  An  Automatic  Tool  for 
Information  Exploration-Hypertext?"  Hypertext 
'87  Papers.  November  13-15,  1987,  Chapel  Hill, 
NC.  New  York:  ACM,  1989.  175-188. 

Robertson,  C.  Kamila  and  Robert  Akscyn. 
"Experimental  Evaluation  of  Tools  for  Teaching  the 
ZOG  Frame  Editor."  Proceedings  of  the 
International  Conference  on  Man-Machine  Systems. 
Manchester,  UK: ,  July,  1982.  115-123. 

Robertson,  C.  Kamila,  Donald  L.  McCracken  and 
Alan  Nevv^ell.  The  ZOG  Approach  to  Man-Machine 
Communication,  CMU-CS-79-148.  Department  of 
Computer  Science,  Carnegie-Mellon  University, 
Pittsburgh,  PA,  October  1979. 

Rubens,  Philip.  "Online  Information,  Hypermedia, 
and  the  Idea  of  Literacy."  in  The  Society  of  Text: 
Hypertext,  Hypermedia,  and  the  Social 
Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA:  The  MIT  Press,  1989.  3-21. 

Saffo,  P.  "What  You  Need  to  Know  about 
Hypertext."  Personal  Computing,  (December,  1987): 
166-173. 

-260-  January  1990 


Savoy,  Jacques.  "The  Electronic  Book  EBOOKS." 
The  International  Journal  of  Man-Machine  Studies, 
(in  press). 

Scacchi,  Walt.  "On  the  Power  of  Domain-Specific 
Hypertext  Environments."  Journal  of  American 
Society  for  Information  Science,  Vol.  40,  No.  3  (May 
1989):  183-191. 

Schatz,  Bruce  R.  Telesophy:  A  System  for  Browsing 
and  Sharing  Inside  a  Large  Information  Space,  TM- 
ARH-006-094.  Bell  Communications  Research, 
Morristown,  NJ,  September  1986. 

Schatz,  Bruce  R.  and  Michael  A.  Caplinger. 
"Searching  in  a  Hyperlibrary."  Proceedings  Fifth 
International  Conference  on  Data  Engineering. 
February  1989,  Los  Angeles.  IEEE.  188-197. 

Schnase,  John  L.  and  John  J.  Leggett. 
"Computational  Hypertext  in  Biological 
Modeling."  Hypertext  '89  Proceedings.  November  5- 
7,  1989,  Pittsburgh,  PA.  New  York:  ACM,  1989.  181- 
198. 

Scully,  John.  "The  Relationship  between  Business 
and  Higher  Education:  A  Perspective  on  the 
Twenty-First  Century."  Educom  Bulletin,  (Spring, 
1988):  20-24. 

Seybold,  P.  B.  "Tymshare's  Augment:  Heralding  a 
New  Era."  Seybold  Report  on  Word  Processing,  Vol. 
1,  No.  9  (October  1978):  M6. 

Shapiro,  Ezra.  "A  First  Look  at  Dayflo."  Byte,  Vol. 
9,  No.  3  (March  1984):  81-87. 

Shasha,  Dennis.  "NetBook— A  Data  Model  to 
Support  Knowledge  Exploration."  Proceedings  of 
the  Eleventh  International  Conference  on  Very 
Large  Data  Bases.  Stockholm,  August,  1985. 

Shasha,  Dennis.  "When  Does  Non-linear  Text 
Help?"  Proceedings  of  the  Expert  Database 
Systems  Conference.  1986,  New  York:  ACM,  1986. 

Shipman,  Frank  III,  Jesse  Chaney  and  G.  Anthony 
Gorry.  "Distributed  Hypertext  for  Collaborative 
Research:  The  Virtual  Notebook  System." 
Hypertext  '89  Proceedings.  November  5-7,  1989, 
Pittsburgh,  PA.  New  York:  ACM,  1989. 129-13b. 

Shneiderman,  Ben.  "User  Interface  Design  and 
Evaluation  for  an  Electronic  Encyclopedia."  Pro- 
ceedings of  the  2nd  International  Conference  on 
Human-Computer  Interaction.  August,  1987, 
Honolulu,  HI. 


Shneiderman,  Ben.  "User  Interface  Design  for  the 
Hyperties  Electronic  Encyclopedia."  Hypertext  '87 
Papers.  November  13-15,  1987,  Chapel  Hill,  NC. 
New  York:  ACM,  1989.  199-205. 

Shneiderman,  Ben,  Dorothy  Brethauer,  Catherine 
Plaisant  and  Richard  Potter.  "Evaluating  Three 
Museum  Installations  of  a  Hypertext  System." 
Journal  of  American  Society  for  Information  Science, 
Vol.  40,  No.  3  (May  1989):  172-182. 

Shneiderman,  Ben.  "Reflections  on  Authoring, 
Editing,  and  Managing  Hypertext."  in  The  Society 
of  Text:  Hypertext,  Hypermedia,  and  the  Social 
Construction  of  Information,  Edward  Barrett, 
(editor).  Cambridge,  MA:  The  MIT  Press,  1989.  115- 
131. 

Shneiderman,  Ben  and  Greg  Kearsley.  Hypertext 
Hands-On!  Reading,  MA:  Addison-Wesley,  1989. 

Shneiderman,  Ben,  Philip  Shafer,  Roland  Simon 
and  Linda  J.  Weldon.  Display  Strategies  for 
Program  Browsing:  Concepts  and  an  Experiment, 
CAR-TR-192,  CS-TR-1635.  Department  of  Computer 
Science,  University  of  Maryland,  College  Park, 
MD,  1986. 

Shultz,  Edward  K.,  Roger  W.  Brown  and  J.  Robert 
Beck.  "Hypermedia  in  Pathology-The  Dartmouth 
Interactive  Medical  Record  Project."  American 
Journal  of  Clinical  Pathology,  Vol.  91,  No.  4,  suppl. 
1  (April  1989):  S34-38. 

Smith,  John  B.  and  Stephen  F.  Weiss.  "Hypertext." 
Communications  of  the  ACM,  Vol.  31,  No.  7  (1988): 
816-619. 

Smith,  John  B.,  Stephen  F.  Weiss  and  Gordon  J. 
Ferguson.  "A  Hypertext  Writing  Environment  and 
its  Cognitive  Basis."  Hypertext  '87  Papers. 
November  13-15,  1987,  Chapel  Hill,  NC.  New 
York:  ACM,  1989.  195-214. 

Smith,  John  B.,  Stephen  F.  Weiss,  Gordon  J. 
Ferguson,  Jay  David  Bolter,  M.  Lansman  and  D.  V. 
Beard.  WE;  A  Writing  Environment  for  Pro- 
fessionals, 86-025.  University  of  North  Carolina, 
Department  of  Computer  Science,  Chapel  Hill,  NC, 
August,  1986. 

Smith,  Karen  E.  "Hypertext-Linking  to  the 
Future."  ONLINE  Magazine,  Vol.  12,  No.  2  (March 
1988):  32-40. 


Hypermedia  Bibliography  NISI  Version 


-261- 


January  1990 


Smith,  Karen  E.  and  Stanley  B.  Zdonik. 
"Intermedia:  A  Case  Study  of  the  Differences 
Between  Relational  and  Object-Oriented  Database 
Systems."  Proceedings  of  the  Conference  on  Object- 
Oriented  Programming  Systems,  Languages,  and 
Applications  (OOPSLA  '87).  October  4-8,  Orlando, 
FL.  16 , 1987. 

Smith,  Linda  C.  "'Memex'  as  an  Image  Potentiality 
in  Information  Retrieval  Research  and 
Development."  in  Information  Retrieval  Research, 
R.  N.  Oddy,  (editor).  London:  Butterworths,  1981. 
345-369. 

Smolensky,  Paul,  Brigham  Bell,  Barbara  Fox, 
Roger  King  and  Clayton  Lewis.  "Constraint-based 
Hypertext  for  Argumentation."  Hypertext  '87 
Papers.  November  13-15,  1987,  Chapel  Hill,  NC. 
New  York:  ACM,  1989.  215-246. 

Storrs,  Graham.  "The  Alvey  DHSS  Large 
Demonstrator  Project  Knowledge  Analysis  Tool: 
KANT."  in  Hypertext:  Theory  into  Practice,  Ray 
McAleese,  (editor).  Norwood,  NJ:  Ablex  Publishing 
Corporation,  1989.  148-156. 

Stotts,  P.  David  and  Richard  Furuta.  "Adding 
Browsing  Semantics  to  the  Hypertext  Model." 
Proceedings  of  the  ACM  Conference  on  Document 
Processing  Systems.  December  5-9,  1988,  Santa  Fe, 
NM.  New  York:  ACM,  1988.  43-50. 

Stotts,  P.  David  and  Richard  Furuta.  "Petri  Net 
Based  Hypertext:  Document  Structure  with 
Browsing  Semantics."  ACM  Transactions  on 
Information  Systems,,  Vol.  7,  No.  1  (January  1989): 
3-29. 

Streitz,  Norbert  A.,  Jorg  Hanneman  and  Manfred 
Thuring.  "From  Ideas  and  Arguments  to 
Hyperdocuments:  Travelling  Through  Activity 
Spaces."  Hypertext  '89  Proceedings.  November  5-7, 
1989,  Pittsburgh,  PA.  New  York:  ACM,  1989.  343- 
364. 

Svibely,  J.  R.  and  J.  W.  Smith.  "A  Prototypic 
Hypertext  Information  System  for  Pathologist." 
Informatics  in  Pathology,  Vol.  1  (1986):  133-142. 

Tanguay,  David  A.  A  General  System  for  Managing 
Videotex  Information  Structures,  CS-86-23. 
University  of  Waterloo,  Department  of  Computer 
Science  Technology,  June  1986. 

Tchudi,  S.  "Invisible  Thinking  and  the  Hypertext." 
English  Journal,  Vol.  77,  No.  1  (1988):  22-30. 


Thompson,  Bev  and  Bill  Thompson.  "Hyping  Text: 
Hypertext  and  Knowledge  Representation."  AI 
Expert,  (August,  1987):  25-28. 

Thorsen,  Linda  J.  and  Mark  Bernstein.  "Developing 
Dynamic  Documents:  Special  Challenges  for 
Technical  Communicators."  Proceedings  of  the  34th 
International  Technical  Communications 
Conference.  Denver,  CO,  1987. 

Thursh,  Donald,  Frank  Mabry  and  Allan  H.  Levy. 
"Computers  and  Videodiscs  in  Pathology 
Education:  ECLIPS  as  an  Example  of  One 
Approach."  Human  Pathlology,  Vol.  17  (1986):  216- 
218. 

Thursh,  Donald  and  Frank  Mabry.  "A  Knowledge- 
Based  Hypertext  of  Pathology."  Proceedings  of  the 
Fourth  Annual  Symposium  on  Computer 
Applications  in  Medical  Care,  1980. 

Thursh,  Donald  and  Frank  Mabry.  "A  Knowledge- 
Based  System  for  Pathology  Education."  Bulletin  of 
Pathology  Education,  Vol.  6,  No.  2  (Fall  1980):  36- 
45. 

Thursh,  Donald,  Frank  Mabry  and  Allan  H.  Levy. 
"The  Knowledge  Access,  Management,  and 
Extension  System  in  Pathology."  Proceedings  of  the 
AAMSI  Congress.  Allan  H.  Levy  and  B.  T. 
Williams,  (editors),  1985. 

Tompa,  Frank  Wm.  "A  Data  Model  for  Flexible 
Hypertext  Database  Systems."  ACM  Transactions 
on  Information  Systems,  Vol.  7,  No.  1  (January 
1989):  85-100. 

Tompa,  Frank  Wm.  "Retrieving  Data  through 
Telidon."  Proceedings  CIPS,  1982. 

Tompa,  Frank  Wm,  Jan  Gecsei  and  Gregor  V. 
Bochmann.  "Alternative  Database  Facilities  for 
Videotex."  in  The  Telidon  Book,  D.  Godfrey  and  E. 
Chang,  (editors).  Press  Porcepic,  1981. 

Travers,  Michael.  "A  Visual  Representation  for 
Knowledge  Structures."  Hypertext  '89  Proceedings. 
November  5-7,  1989,  Pittsburgh,  PA.  New  York: 
ACM,  1989. 147-158. 

Trigg,  Randall  H.  "A  Networked-based  Approach 
to  Text  Handling  for  the  On-line  Scientific 
Community."  University  of  Maryland,  1983. 

Trigg,  Randall  H.  "Guided  Tours  and  Tabletops: 
Tools  for  Communicating  in  a  Hypertext  En- 
vironment." ACM  Transactions  on  Office 
Information  Systems,  Vol.  6,  No.  4  (October  1988): 
398-414. 


Hypermedia  Bibliography  NISI  Version 


-262- 


January  1990 


Trigg,  Randall  H.  and  Peggy  M.  Irish.  "Hypertext 
Habitats:  Experiences  of  Writers  in  NoteCards." 
Hypertext  '87  Papers.  November  13-15,  1987, 
Chapel  Hill,  NC.  New  York:  ACM,  1989.  89-108. 

Trigg,  Randall  H.,  Thomas  P.  Moran  and  Frank  G. 
Halasz.  "Adaptibility  and  Tailorability  in 
NoteCards."  Proceedings  of  INTERACT  '87. 
September,  Stuttgart,  West  Germany.  1987. 

Trigg,  Randall  H.  and  Lucy  A.  Suchman. 
"Collaborative  Writing  in  NoteCards."  in 
Hypertext:  Theory  into  Practice,  Ray  McAleese, 
(editor).  Norwood,  NJ:  Ablex  Publishing 
Corporation,  1989.  45-61. 

Trigg,  Randall  H.,  Lucy  A.  Suchman  and  Frank  G. 
Halasz.  "Supporting  Collaboration  in  NoteCards." 
Computer-Supported  Cooperative  Work  (CSCW 
'86)  Proceedings.  December  3-5,  Austin,  TX,  1986. 
153-162. 

Trigg,  Randall  H.  and  Mark  Weiser.  "TEXTNET:  A 
Network-Based  Approach  to  Text  Handling."  ACM 
Transactions  on  Office  Information  Systems,  Vol  4, 
No.  1  (January,  1986):  1-23. 

Tsai,  C.  "Hypertext:  Technology,  Applications,  and 
Research  Issues."  Journal  of  Educational  Technology 
Systems,  Vol.  17,  No.  1  (1988):  3-14, 

Underwood,  J.  "Language  Learning  and 
•Hypermedia"."  ADFL  Bulletin,  Vol,  19,  No.  4 
(1988):  13-17. 

Utting,  Kenneth  and  fJicole  Yankelovich.  "Context 
and  Orientation  in  Hypermedia  Netv/orks."  ACM 
Transactions  on  Information  Systems,  Vol.  7,  No.  1 
(January,  1989):  58-84. 

van  Dam,  Andries.  PRESS  (File  Retrieval  and 
Editing  System).  Barrington,  RI:  Text  Sj'stems,  July 
1971. 

van  Dam,  Andries.  "Hypertext  '87  Keynote 
Address."  Communications  of  the  ACM,  Vol.  31, 
No.  7  (July  1988):  887-895. 

van  Dam,  Andries  and  David  E.  Rice.  "Computers 
and  Publishing:  Writing,  Editing  and  Printing."  in 
Advances  in  Computers,  New  York:  Academic  Press, 
1970. 

van  Dam,  Andries  and  David  E.  Rice.  "On-Liae 
Text  Editing:  A  Survey/'  Computing  Surveys,  Vol 
3,  No.  3  (September  1971):  93-114, 


van  der  Merwe,  D.  P.  "Annotating  Literary  Texts 
with  Hypertext."  Proceedings  of  the  12th  In- 
ternational Online  Information  Meeting.  December 
6-8, 1988,  London,  England.  Oxford  and  New  Jersey: 
Learried  Information,  1988.  239-247. 

VanLehn,  Kurt.  Theory  Reform  Caused  by  an 
Argumentation  Tool,  ISL-11.  Xerox  Palo  Alto 
Research  Center,  July,  1985. 

V\^<k\ker,  Donald.  Knowledge  R.esource  Tools  for 
Accessing  Large  Text  Files,  85-21233-25.  Bell 
Communications  Research,  1985. 

Walker,  Janet  H.  "The  Document  Editor:  A  Support 
Environment  for  Preparing  Technical  Documents." 
Proceedings  of  the  ACM  SIGPLAN  jSIGOA 
Conference  on  Text  Manipulation.  Portland,  OR:  , 
June  1981. 44-50. 

Walker,  Janet  H.  "Symbolics  Sage:  A  Doc- 
umentation Support  System."  Intellectual  Lever- 
age: The  Driving  Technologies,  IEEE  Spring 
Compcon84,  1984.  478-183. 

Walker,  Janet  H.  "Document  Examiner:  Delivery 
Interface  for  Hypertext  Documents."  Hypertext  '87 
Papers.  November  13-15,  1987,  Chapel  Hill,  NC. 
Nev/  York:  ACM,  1989.  307-324. 

Walker,  Janet  H.  "The  Role  of  Modularity  in 
Document  Authoring  Systems."  Proceedings  of  the 
ACM  Conference  on  Document  Processing  Systems. 
December  5-9,  1988,  Santa  Fe,  New  Mexico.  New 
York:  ACM,,  1988. 117-124. 

Walker,  Janet  H.  "Supporting  Document  De- 
velopment in  Concordia."  IEEE  Computer,  (January, 
1988):  48-59. 

Walker,  Janet  H.  "Authoring  Tools  for  Complex 
Document  Sets."  in  The  Society  of  Text:  Hypertext, 
Hypermedia,  and  the  Social  Construction  of 
Information,  Edward  Barrett,  (editor).  Cambridge, 
MA:  The  MIT  Press,  1989. 132-147. 

Walker,  Janet  H.  and  R.  L.  Bryan.  "An  Editor  for 
Structured  Technical  Documents."  Protext  IV. 

Walter,  Mark.  "IRIS's  Intermedia:  Multiuser  Hy- 
pertext." Seybold  Report  on  Publishing  Systems, 
Vol.  18,  No.  21  (August  7,  1989):  20-32. 

Weyer,  Stephen  A.  "As  We  May  Learn."  in 
Interactive  Multimedia,  Sueann  Ambron  and 
Kristina  Hooper,  (editors).  Redmond,  WA: 
Microsoft  Press,  1988.  87-104. 


Hypermedia  Bibliography  N!ST  Version 


-263- 


January  1990 


Weyer,  Stephen  A.  "The  Design  of  a  DynaiTiic  Book 
for  Information  Search."  International  Journal  of 
Man-Machine  Studies,  Vol.  17,  No.  1  (July  1982): 
87-107. 

Weyer,  Stephen  A.  Searching  for  Information  in  a 
Dynamic  Book,  Report  SCG-1  (Also  published  as  a 
Stanford  University  dissertation).  Xerox  Palo  Aito 
Research  Center,  Palo  Alto,  CA,  February  1982. 

Weyer,  Stephen  A.  and  Alan  H.  Borning.  "A 
Prototype  Electronic  Encyclopedia."  ACM  Trans- 
actions on  Office  Information  Systems,  Vol.  3,  No.  1 
(January  1985):  63-88. 

White,  J.  E.  "A  High-Level  Framework  for 
Network-based  Resource  Sharing."  AFIPS  Pro- 
ceedings, National  Computer  Conference.  June  7-10, 
1976,  New  York.  Montvale,  New  Jersey:  AFIPS 
Press,  1976.  561-570. 

Wilder,  H.  A.  and  Nick  F.  Maxemchuck.  "Virtual 
Editing:  II.  The  User  Interface."  Proceedings  of 
SIGOA  Conference  Office  Automation  Systems.  June 
21-23,  Philadelphia,  PA.  New  York:  ACM,  1982. 
41-46. 

Wilson,  Kathleen  S.  Palenque:  An  Interactive 
Multimedia  Optical  Disk  Prototype  for  Children. 
Working  Paper  No.  2,  Bank  Street  College  of 
Education,  Center  for  Children  and  Technology, 
New  York,  1987. 

Wilson,  Kathleen  S.  "Palenque:  An  Interactive 
Multimedia  Digital  Interactive  Prototype  for 
Children."  Proceedings  of  the  1988  ACM  Conference 
on  Human  Factors  in  Computer  Systems  (CHI  '88), 
May  15-19,  Washington,  D.C.  New  York:  ACM, 
1988.  275-279. 

Woods,  William  A.  "What's  in  a  Link:  Foundations 
for  Semantic  Networks."  in  Readings  in  Knowledge 
Representation,  Ronald  J.  Brachman  and  Hector  J. 
Levesque,  (editors).  Los  Altos,  CA:  Morgan 
Kaufmann,  1975. 

Yankelovich,  Nicole.  "The  Sampler  Companion: 
Four  Educational  Software  Samples."  Proceedings 
of  Frontiers  in  Education  Fifth  Annual  Conference. 
October  19-22,  Golden,  CO,  1985. 

Yankelovich,  Nicole,  L.  Nancy  Garrett,  Karen  E. 
Smith  and  Norman  Meyrowitz.  "Issues  in  Designing 
a  Hypermedia  Document  System:  The  Intermedia 
Case  Study."  in  Interactive  Multimedia,  Sueann 
Ambron  and  Kristina  Hooper,  (editors).  Redmond, 
WA:  Microsoft  Press,  1988.  33-86. 


Yankelovich,  Nicole,  Bernard  Haan  and  Steven 
Drucker.  "Connections  in  Context:  The  Intermedia 
System."  Proceedings  of  the  Twenty-First  Annual 
Hawaii  International  Conference  on  System 
Sciences.  Bruce  D.  Shriver,  (editor).  January  5-8, 
1988,  Kailua-Kona,  HA.  Washington,  D.C:  Com- 
puter Society  Press  of  the  IEEE.  715-724. 

Yankelovich,  Nicole,  Bernard  J.  Haan,  Norman 
Meyrowitz  and  Steven  M.  Drucker.  "Intermedia: 
The  Concept  and  the  Construction  of  a  Seamless 
Information  Environment."  IEEE  Computer,  Vol.  21, 
No.  1  (January  1988):  81-96. 

Yankelovich,  Nicole,  George  Landow  and  Peter 
Heywood.  Designing  Hypermedia  "Ideahases" — 
The  Intermedia  Experience,  Technical  Report  87-4. 
IRIS,  Brown  University,  Providence,  RI,  1987. 

Yankelovich,  Nicole,  Norman  Meyrowitz  and 
Andries  van  Dam.  "Reading  and  Writing  the 
Electronic  Book."  IEEE  Computer,  Vol.  18,  No.  10 
(October  1985):  16-30. 

Yankelovich,  Nicole  and  Andries  van  Dam. 
"Spinning  Scholarly  Webs."  The  Annenberg/CPB 
Project  Report  to  Higher  Education,  The  An- 
nenberg/ CPB  Project,  Washington,  D.C,  1987. 

Yoder,  Elise  A.,  Robert  M.  Akscyn  and  Donald  L. 
McCracken.  "Collaboration  in  KMS,  A  Shared 
Hypermedia  System."  Proceedings  of  the  1989  ACM 
Conference  on  Human  Factors  in  Computer  Systems 
(CHI  '89),  April  30-May  4,  1989,  Austin,  TX.  New 
York:  ACM,  1989.  37-42. 

Yoder,  Elise  and  Thomas  C.  Wettach,  Esq.  "Using 
Hypertext  in  a  Law  Firm."  Hypertext  '89  Pro- 
ceedings. November  5-7,  1989,  Pittsburgh,  PA.  New 
York:  ACM,  1989. 159-168. 

Young,  Jeffrey  S.  "Hypermedia."  MacWorld,  Vol.  3, 
No.  3  (March  1986):  116-121. 

Zellweger,  Polle  T.  "Active  Paths  Through 
Multimedia  Documents."  Proceedings  of  the  EP  '88 
Conference  on  Electronic  Publishing,  Document 
Manipulation  and  Typography.  April  20-22,  1988, 
Nice,  France. 

Zellweger,  Polle  T.  "Scripted  Documents:  A  Hy- 
permedia Path  Mechanism."  Hypertext  '89  Pro- 
ceedings. November  5-7,  1989,  Pittsburgh,  PA.  New 
York:  ACM,  1989.  M4. 


Hypermedia  Bibliography  NISI  Version 


-264- 


January  1990 


Participants  List 
Hypertext  Standardization  Workshop 


Carol  A.  Adams 
IBM 

1 1400  Bumet  Rd. 
Austin,  TX  78758 

Peter  Aiken 

George  Mason  University 
MS  ST-203 

Fairfax,  VA  22030-4444 
paikenCg)  gmuv  ax2.gmu.edu 

Robert  Akscyn 
Knowledge  Systems  Inc. 
4750  Old  WilUam  Penn  Hwy. 
MurrysviUe,  PA  15668 

Frank  Armour 

George  Mason  University 

MS  ST-203 

Fairfax,  VA  22030-4444 
JeanBaronas 

National  Institute  of  Standards  &  Technology 
Room  B263,  Bldg.  225 
Gaithersburg,  MD  20899 
baronas(2)  asl.ncsl.nist.gov 

Denise  A.  D.  Bedgord 
Consultant 
12307  Lima  Drive 
Silver  Spring,  MD  20904 

Daniel  R.  Benigni 

National  Institute  of  Standards  &  Technology 
Room  A266,  Bldg.  225 
Gaithersburg,  MD  20899 
benigm@ise.ncsl.nist.gov 


Tim  Bcrncrs-Lcc 
CERN 

1211  Geneva  23 

SWITZERLAND 

tim@online.cem.ch 

James  D.  Black 

House  of  Representatives 

MS-H2635 

US  House  of  Representatives 
Washington,  DC  20515 
fjb(2)mios.house.gov 

A.  R.  Briggs 
Xerox  Corporation 
2000  Corp.  Ridge 
McLean,  VA  22102 

Diane  Brown 
Mitre  Corporation 
7525  Colshire  Drive 
Mailcode  Z580 
McLean,  VA  22102 

Karin  Bruce 

James  Martin  Associates 
1850  Centennial  Pk  Drive 
Suite  200 
Reston,  VA  22091 

John  C.  Chen 
Texas  Instruments 
P.O.  Box  655474 
MS  238 

DaUas.TX  75265 
jcen(a)csc.ti.com 


-265- 


Qi  Fan  Chen 

Virginia  Tech 

Dept.  of  Computer  Science 

552  McBryde  Hall 

Blacksburg,  VA  24061 

chenq%fox(a)vtopus. cs.vt.edu 

Paul  Clapis 

Hughes  Danbury  Optical  Sy 
25  Science  Pk 
New  Haven,  CT  06511 
cl  api  s(S)  celrax .  y  ale  .c  s .  edu 

Fred  Cole 

Computing  Laboratory 
University  of  Kent 
Canterbury 
KentCT2  7NF 
ENGLAND 
fcc@ukc.ac.wk 

Joe  Collica 

National  Institute  of  Standards  &  Technology 
Room  A266,  Bldg.  225 
Gaithersburg,  MD  20899 
collica(2)ise.ncsl.nist.gov 

Gregory  Crane 
Harvard  University 
Perseus  Project 
Dept.  of  Classics 
319Boylston  Hall 
Cambridge,  MA  02138 
cr  anecg)  wj  hl2  .harv  ard.  edu 

Andrew  Dove 
Landmark  Graphics 
333  Cypress  Run 
Houston,  TX  77094 
andrew@lgc.com 

Edward  Edmiston 
Mitre  Corporation 
7525  Colshire  Drive 
Mailcode  Z580 
McLean,  VA  22102 


Lawrence  E.  Fitzpatrick 
Personal  Library  Software 
15215  Shady  Grove  Rd 
Suite  204 

RockviUe,  MD  20850 

Valerie  Florance 
Welch  Med  Library,  JHU 
1830  Monument  Street 
3rd  Floor 

Baltimore,  MD  21205 
vf@welchlab.jhu.edu 

Dr.  Edward  A.  Fox 

Dept.  of  Computer  Science 

562  McBr>'de  Hall 

VPI&SU  (Virginia  Tech) 

Blacksburg,  VA  24016-0106 

fox@vtopus.cs.vt.edu 

David  Fristrom 

Interleaf 

10  Canal  Park 

Cambridge,  MA  02141 

Richard  Furuta 

Dept.  of  Computer  Science 

University  of  Maryland 

College  Park,  MD  20742 

furuta@cs.umd.edu 

Leonard  Gallagher 

National  Institute  of  Standards  &  Technolog 
Room  A266,  Bldg.  225 
Gaithersburg,  MD  20899 
gallagher@ise.ncsl.nist.gov 

Kevin  Gamble 
USDA 

3322  Smith  Bldg. 
Washington,  DC  202500-0900 
kgamble@cas.orst.edu 


-266- 


Bob  Glushko 
Search  Technology,  Inc 
4725  Peachtree  Comers  Circle 
Suite  200 

Norcross.GA  30092 
srchtec!glushko@gatech.edu 

Louis  Gomez 

Bellcore 

445  South  Street 

Morristown,  NJ  07961 

gomez@  bellcore .  com 

Frank  Halasz 

Systems  Sciences  Laboratory 
Xerox  Palo  Alto  Research  Center 
3333  Coyote  Hill  Road 
Palo  Alto,  CA  94304 
halasz@xerox.com 

Seymour  Hanfling 

US  Army  Research  Institute 

5001  Eisenhower  Avenue 

PREI-IC 

Alexandria,  VA  22333 

Dr.  Shoshana  Hardt-Komacki 

Bellcore 

2A-273 

445  South  Street 
Morristown,  NJ  07961 
shoshi@bellcore.com 

Michael  Hogan 

National  Institute  of  Standards  &  Technology 
Room  B168,  Bldg.  225 
Gaithersburg,  MD  20899 

Kris  Houlahan 
DEC 

8300  Professional  PI 
Suite  119 

Landover,MD  20785 


Danny  B.  Lange 

Bruel  &  Kjacr  Industri  A/S 

Department  of  Development 

DK-2850  Nacrum 

DENMARK 

danny.lange@bk.dk 

John  J.  Leggett 
Hypertext  Research  Lab 
Dept.  of  Computer  Science 
Texas  A&M  University 
CoUege  Station,  TX  77843-31 12 
leggett@cssun.tamu.edu 

William  P.  Loftus 
Unisys  Corporation 
Rt.  252  &  Central 
1300  Wing 
PaOli,PA  19301 
wpl@prc.unisys.com 

Kathryn  C.  Malcolm 
Boeing  Computer  Corporation 
P.O.  Box  24346 
Seattle,  WA  98124-0346 

Catherine  Marshall 
Systems  Sciences  Laboratory 
Xerox  Palo  Alto  Research  Center 
3333  Coyote  Hill  Road 
Palo  Alto,  CA  94304 
marshall@xerox.com 

Robert.  Smith  Midford 
Federal  Computer  Week 
4141  N.  Anderson 
413 

Arlington,  VA  22203 

Robert  Miglin 
ANSER  Analytic  Services 
Crystal  Gateway  3,  Suite  800 
1215  Jefferson  Davis  Hwy. 
Arlington,  VA  22202 


-267- 


Judi  Moline 

National  Institute  of  Standards  &  Technology 
Room  B266,  Bldg.  225 
Gaithersburg,  MD  20899 
molineCg)  asl.ncsl.nist.gov 

Howard  Moncarz 
NIST 

Metrology,  Rm  A 127 
Gaithersburg,  MD  20899 
moncarz(a)cme.nist.gov 

Fontaine  Moore 
CACI,  Inc.-Federal 
8260  Willow  Oaks  Drive 
Fairfax,  VA  22031 

Prof.  Steven  R.  Newcomb 
Center  for  Music  Research 
Florida  State  University 
Tallahassee,  FL  32306-2098 
cmr!sm(a)bikini.cis.ufl.edu 

Charles  K.  Nicholas 
Computer  Sciences  Dept. 
U.M.B.C. 

5401  Wilkens  Avenue 
Catonsville,  MD  21228 

Dan  Olson 

Boeing  Computer  Services 
P.O.  Box  24346  #6498 
Seattle,  WA  98124 

Tim  Oren 

Apple  Computer  Advanced  Technology  Group 
Apple  Computer,  Inc. 
20525  Mariani  Ave. 
MS  76-2C 

Cupertino,  CA  95014 
oren(S)  apple.com 


Taeha  Park 

KAIST 

P.O.Box  150 

Chongryang-Dongdaeno 

Seoul 

KOREA 

taeha@sorak.kaist.ac.kr 

H.  Van  Dyke  Parunak 

Industry  Technology  Institute 

P.O.  Box  1485 

Ann  Arbor,  MI  48106 

van@iti.org 

Kenneth  Pugh 

Information  Navigation,  Inc. 
4201  University  Drive,  Suite  102 
Durham,  NC  27707 

John  J.  Puttress 
AT&T  Bell  Laboratories 
600  Mountain  Ave. 
2C-577 

Murray  Hill,  NJ  07974 
jp(a)bashful.att.com 

Victor  Riley 
IRIS/Brown  University 
155  George  Street 
Box  1946 

Providence,  RI 02906 
var(5)iris.brown.edu 

Louis  G.  Roberts 
Boeing  Computer  Services 
P.O.  Box  24346 
SeatUe,WA  98124-0346 
lroberts@atc.boeing.com 

Linda  Rosenberg 
Goucher  College 
Towson,MD  20214 
linda@cs.umbc.edu 


-268- 


Sean  Sebastian 
GE  Info  Systems 
401  N.  Washington  St. 
MC  OTCY 

Rockville,  MD  20850 
Andrea  Spinelli 

Bull  HN  Information  Systems  Italia  S.p.A 
Via  Vittor  Pisani,  10 
20100  Miiano 
ITALY 

Duane  Stone 

McDonnell  Douglas 

P.O.  Box  516 

MS  100  2125 

St.  Louis,  MO  63166 

stone@team-l  .mdc.com 

David  Stotts 
University  of  Maryland 
Dept.  of  Computer  Science 
CoUege  Park,  MD  20742 
pds@cs.umd.edu 

Craig  W.  Thompson 
Info.  Tech.  Laboratory 
Texas  Instruments  Inc. 
P.O.  Box  655474,  MS  238 
Dallas,  TX  75265 
thompson(a)csc.t.i.com 

CHfford  Urr 

Planning  Analysis  Corporation 
Suite  890 

1010  North  Glebe  Road 
Arlington,  VA  22201 

Janet  H.  Walker,  Ph.D 
Digital  Equipment  Corp. 
One  Kendall  Square 
Bldg.  700 

Cambridge,  MA  02139 
jwalker(a)  crl.dec.com 


David  Wojick 
CACI,  Inc.-Federal 
8260  Willow  Oaks  Drive 
11/8 

Fairfax,  VA  22031 

Magdalena  Wright 
GMA  Industries 
P.O.Box  16248 
Arlington,  VA  22215 

Donald  Young 
McDonnell  Douglas 
Dept.  H093/HQ 
MS  100  2125 
P.O.  Box  516 
St.  Loius,MO  63166 


-269- 


NBS-n4A  iREv.  2-ec) 


U.S.   DEPT.  OF  COMM. 

1.  PUBLICATION  OR 

2.  Performing  Organ.  Report  No, 

3.  Publica 

.ion  Date 

BIBLIOGRAPHIC  DATA 

REPORT  NO. 

SHEET  (See  instructions) 

NIST/SP-500/178 

March 

1990 

4.  TITLE  AND  SUBTITLE 


Proceedings  of  the  Hypertext  Standardization  Workshop 

January  15-18,  1990,  National  Institute  of  Standards  and  Technology 


5.  AUTHOR(S) 

Judi  Moline,  Dan  Benigni,  Jean  Baronas 

6.  PERFORMING  ORGANIZATION  (If  joint  or  other  titan  NBS,  ,=:ee  instructions) 

NATIONAL  INSTITUTE  OF  STANDARDS  AND  TECHNOLOGY 
(lormerly  NATIONAL  BUREAU  OF  STANDARDS) 
U.S.  DEPARTMENT  OF  COMMERCE 
GAITHERSBURQ,  MD  20899 

7.  Contract/Grant  No. 

8.  Type  of  Report  &  Period  Covered 

Final 

9.  SPONSORING  ORGANIZATION  NAME  AND  COMPLETE  ADDRESS  (Street.  City.  State,  ZIP) 


Same  as  item  #6 


10.  SUPPLEMENTARY  NOTES 


|~  I  Document  describes  a  computer  program;  Sh-iSS,  FIPS  Software  Summary,  is  attached. 


11.  ABSTRACT  (A  200-word  or  /ess  factual  summary  of  most  si gnificant  information .   If  document  includes  a  si gnificant 
bi bliography  or  literature  survey,  mention  it  here) 

This  report  constitutes  tlie  proceedings  of  a  three  day  workshop  on  Hypenext 
Standardization  held  at  the  National  Institute  ov  Standards  and  Technology  (NIST)  on 
January  16  -  18,  1990.  Effons  towards  standardization  of  hypertext  have  already  been 
initiated  in  various  interested  organizations.  In  recognition  of  these  existing  effons,  NIST 
sponsored  the  Hypertext  Standardization  Workshop  organized  by  the  Hj'pertext 
Competence  Project  of  the  National  Computer  Systems  Laboratory. 

The  major  purpose  of  the  Hypertext  Standardization  Workshop  was  to  provide  a 
forum  for  presentation  and  discussion  of  existing  and  proposed  approaches  to  hs'pertext 
standardization.  The  stated  workshop  goals  were  to  consider  hypertext  system  definitions, 
to  identify  viable  approaches  for  pursuing  standards,  to  seek  commonality  among 
alternatives  whenever  possible,  and  to  make  progress  towards  a  coordinated  plan  for 
standards  development,  i.e.  a  hypertext  reference  model.  The  workshop  announcement 
solicitated  contributed  papers  on  any  aspect  of  hypertext  standardization,  including 
assertions  that  standardization  is  premature  or  inadvisable.  Approximately  30 
connibutions  were  received  and  distributed  to  the  65  workshop  participants  on  the  first 
day. 

The  workshop  included  plenary  sessions  and  three  discussion  groups.  This 
proceedings  includes  the  papers  selected  for  presentation  in  pleniirj'  sessions,  reports  of 
the  discussion  groups,  and  supplementary'  materials.  Major  conclusions  of  the  workshop 
were  that  the  discussion  groups  should  continue  their  technical  efforts,  and  that  NIST 
should  sponsor  at  least  one  more  workshop  to  provide  a  forum  for  public  discussion  of 
progress. 


12.  KEY  WORDS  (S/x  to  twelve  entries;  alphabetical  order;  capitalize  only  proper  names;  and  separate  key  words  by  semicolons, 

Hypermedia;  hypertext;  standards 


13.  AVAILABILITY 


[X]  Unl  imited 

[    j  For  Official  Distribution.    Do  Not  Release  to  NTIS 

[X]  Order  From  Superintendent  of  Documents,  U.S.  Government  Printing  Office,  Washington,  D.C. 


20402. 


[jp  Order  From  National  Technical  Information  Service  (NTIS).  Springfield,  VA.  22151 


14.  NO.  OF 

PRINTED  PAGES 


259 


15.  Price 


•il^-  U.S.  GOVERNMENT  PRI^m^^GO(-F!CE:  1S90  — 2  El  -913  '20574 


USCCMM-DC  6C43-P80 


ANNOUNCEMENT  OF  NEW  PUBLICATIONS  ON 
COMPUTER  SYSTEMS  TECHNOLOGY 


Superintendent  of  Documents 
Government  Printing  Office 
Washington,  DC  20402 


Dear  Sir: 

Please  add  my  name  to  the  announcement  list  of  new  publications  to  be  issued  in 
the  series:  National  Institute  of  Standards  and  Technology  Special  Publication  500-. 

Name  

Company  

Address  

City  State  Zip  Code  

(Notification  key  N-503) 


NIST 


Technical  Publications 

Periodical 

Journal  of  Research  of  the  National  Institute  of  Standards  and  Technology — Reports  NIST  research 
and  development  in  those  disciplines  of  the  physical  and  engineering  sciences  in  which  the  Institute 
is  active.  These  include  physics,  chemistry,  engineering,  mathematics,  and  computer  sciences. 
Papers  cover  a  broad  range  of  subjects,  with  major  emphasis  on  measurement  methodology  and 
the  basic  technology  underlying  standardization.  Also  included  from  time  to  time  are  survey  articles 
on  topics  closely  related  to  the  Institute's  technical  and  scientific  programs.  Issued  six  times  a  year. 

Nonperiodicals 

Monographs — Major  contributions  to  the  technical  literature  on  various  subjects  related  to  the 
Institute's  scientific  and  technical  activities. 

Handbooks — Recommended  codes  of  engineering  and  industrial  practice  (including  safety  codes)  de- 
veloped in  cooperation  with  interested  industries,  professional  organizations,  and  regulatory  bodies. 
Special  Publications — Include  proceedings  of  conferences  sponsored  by  NIST,  NIST  annual  reports, 
and  other  special  publications  appropriate  to  this  grouping  such  as  wall  charts,  pocket  cards,  and 
bibliographies. 

Applied  Mathematics  Series — Mathematical  tables,  manuals,  and  studies  of  special  interest  to  physi- 
cists, engineers,  chemists,  biologists,  mathematicians,  computer  programmers,  and  others  engaged  in 
scientific  and  technical  work. 

National  Standard  Reference  Data  Series — Provides  quantitative  data  on  the  physical  and  chemical 
properties  of  materials,  compiled  from  the  world's  literature  and  critically  evaluated.  Developed  un- 
der a  worldwide  program  coordinated  by  NIST  under  the  authority  of  the  National  Standard  Data 
Act  (Public  Law  90-396).  NOTE:  The  Journal  of  Physical  and  Chemical  Reference  Data  (JPCRD) 
is  published  quarterly  for  NIST  by  the  American  Chemical  Society  (ACS)  and  the  American  Insti- 
tute of  Physics  (AIP).  Subscriptions,  reprints,  and  supplements  are  available  from  ACS,  1155  Six- 
teenth St.,  NW.,  Washington,  DC  20056. 

Building  Science  Series — Disseminates  technical  information  developed  at  the  Institute  on  building 
materials,  components,  systems,  and  whole  structures.  The  series  presents  research  results,  test 
methods,  and  performance  criteria  related  to  the  structural  and  environmental  functions  and  the 
durability  and  safety  characteristics  of  building  elements  and  systems. 

Technical  Notes — Studies  or  reports  which  are  complete  in  themselves  but  restrictive  in  their  treat- 
ment of  a  subject.  Analogous  to  monographs  but  not  so  comprehensive  in  scope  or  definitive  in 
treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final  reports  of  work  performed  at  NIST 
under  the  sponsorship  of  other  government  agencies. 

Voluntary  Product  Standards — Developed  under  procedures  published  by  the  Department  of  Com- 
merce in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish  nationally 
recognized  requirements  for  products,  and  provide  all  concerned  interests  with  a  basis  for  common 
understanding  of  the  characteristics  of  the  products.  NIST  administers  this  program  as  a  supplement 
to  the  activities  of  the  private  sector  standardizing  organizations. 

Consumer  Information  Series — Practical  information,  based  on  NIST  research  and  experience,  cov- 
ering areas  of  interest  to  the  consumer.  Easily  understandable  language  and  illustrations  provide  use- 
ful background  knowledge  for  shopping  in  today's  technological  marketplace. 
Order  the  above  NIST  publications  from:  Superintendent  of  Documents,  Government  Printing  Office, 
Washington,  DC  20402. 

Order  the  following  NIST  publications — FIPS  and  NISTIRs—from  the  National  Technical  Information 
Service,  Springfield,  VA  22161. 

Federal  Information  Processing  Standards  Publications  (FIPS  PUB)— Publications  in  this  series  col- 
lectively constitute  the  Federal  Information  Processing  Standards  Register.  The  Register  serves  as 
the  official  source  of  information  in  the  Federal  Government  regarding  standards  issued  by  NIST 
pursuant  to  the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended,  Public  Law 
89-306  (79  Stat.  1127),  and  as  implemented  by  Executive  Order  11717  (38  FR  12315,  dated  May  11, 
1973)  and  Part  6  of  Title  15  CFR  (Code  of  Federal  Regulations). 

NIST  Interagency  Reports  (NISTIR) — A  special  series  of  interim  or  final  reports  on  work  performed 
by  NIST  for  outside  sponsors  (both  government  and  non-government).  In  general,  initial  distribu- 
tion is  handled  by  the  sponsor;  public  distribution  is  by  the  National  Technical  Information  Service, 
Springfield,  VA  22161,  in  paper  copy  or  microfiche  form. 


U.S.  Department  of  Commerce 

National  Institute  of  Standards  and  Technology 
(formerly  National  Bureau  of  Standards) 
Gaithersburg,  MD  20899 

Official  Business 

Penalty  for  Private  Use  $300